6:04 a.m.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:12 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Kevin Conner commented on JBESB-2301:
-------------------------------------
There are a number of ways in which we can address this, for example handling the creation
of the clients ourselves, using AOP (similar to JBESB-704) to intercept calls or a mixture
of both.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:39 a.m.
New subject: [JBoss JIRA] Work started: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Work on JBESB-2301 started by Daniel Bevenius.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:06 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Kevin Conner commented on JBESB-2301:
-------------------------------------
One other issue that needs to be addressed is the mapping within the
WSEndpoint.getWSMethods() method.
This method creates a mapping (on every invocation!!!) and is supposed to use the
soapAction as the key. Unfortunately it is using the *method name* from the class as the
key.
We need to intercept this method and cache the map, using the soapAction as the key.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:02 p.m.
New subject: [JBoss JIRA] Commented: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Stefano Maestri commented on JBESB-2301:
----------------------------------------
Regarding last kevin's comment. I have recalled why method name is used instead of
soapAction: from JAXWS specification:
"Each wsdl:operation in a wsdl:portType is mapped to a Java method in the
corresponding Java service
endpoint interface.
(Method naming): In the absence of customizations, the name of a mapped Java method
MUST be the value of the name attribute of the wsdl:operation element mapped according to
the rules
described in section 2.8.
An application MAY customize this mapping using the jaxws:method binding declaration
defined in
section 8.7.3.
October 20, 2006 JAX-WS 2.0 11
Chapter 2. WSDL 1.1 to Java Mapping
(javax.jws.WebMethod required): A mapped Java method MUST be annotated with a
javax.jws.WebMethod annotation. The annotation MAY be omitted if all its properties would
have the
default values.
The WS-I Basic Profile[18] R2304 requires that operations within a wsdl:portType have
unique values
for their name attribute so mapping of WS-I compliant WSDL descriptions will not generate
Java interfaces
with overloaded methods"
This part assure that * method name is unique (no overloading method) * in generated
classes. Moreover since operation name (that is also the mathod name) is the only thing we
have in generated classes because soap action is not mandatory and is legal to haven't
it specified.
So the key of the map is correctly the method name, the *BAD THING* is the name of the
attribute I have used in config files.
It take sometime to recall the reasons of this choice, but this part of wise has been
coded years ago and no more changed (at least since donation).
The only case where JAX-WS permit method name overload is using binding files, but they
aren't supported by wise included in ESB 4.4 (they are supported by Wise-1.0 and we
are investigating about in linked issue
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:12 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Kevin Conner commented on JBESB-2301:
-------------------------------------
Okay, having discussed this with Stefano and read up on the specs we have a way forward
for the mapping.
There is an issue with the SOAPClient action in that is specifies a soapAction parameter
whereas what it *really* wants is the operationName. (this probably means that the
*other* SOAPclient is also incorrect)
The soapAction is not guaranteed to be present and, although there are default mappings
that can be applied to the WSDL 1.1 and WSDL 2.0 information, it is not guaranteed to be
unique.
In the same vein, the method name cannot be guaranteed to be unique as it is possible to
specify bindings that alter the default generation.
The only unique attribute is the operationName and this will be present, as part of the
@WebMethod annotation, if it has been overridden by a binding. We should be checking for
this value and using it, falling back to the method name if it is not present.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:14 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Kevin Conner commented on JBESB-2301:
-------------------------------------
In addition, bindings can be specified as part of the WSDL provided the tooling supports
it. it is not necessary to have binding files.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:20 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Daniel Bevenius commented on JBESB-2301:
----------------------------------------
I had a look at this and I think it might be better if Stefano took care of it.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:12 p.m.
New subject: [JBoss JIRA] Resolved: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Daniel Bevenius resolved JBESB-2301.
------------------------------------
Resolution: Partially Completed
Committed to JBESB_4_4_GA_CP with revision 24896.
Leaving this as partially completed to get feedback from Kev and Stefano.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:20 a.m.
New subject: [JBoss JIRA] Reopened: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Kevin Conner reopened JBESB-2301:
---------------------------------
Assignee: Kevin Conner (was: Daniel Bevenius)
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Kevin Conner
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:11 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Kevin Conner commented on JBESB-2301:
-------------------------------------
Just been going through some of the changes and noticed that SmooksCache is also an
issue.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Kevin Conner
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:33 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Kevin Conner commented on JBESB-2301:
-------------------------------------
I have been debugging the wise codebase and found that the Port handling is, in fact, safe
in this version of wise. The codebase we are using creates a new WSEndpoint/proxy for
every message passing through the pipeline and they are not reused.
The invocation aspect appears to only be relevant for the trunk version of wise, and hence
ESB 4.5.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Kevin Conner
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:54 a.m.
New subject: [JBoss JIRA] Closed: (JBESB-2301) Handle wise threading/pooling
[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Kevin Conner closed JBESB-2301.
-------------------------------
Resolution: Done
I believe all the issues identified in this JIRA have now been addressed.
Final commit is 24928.
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL: https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Kevin Conner
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6287
days inactive
6291
days old
12 comments
3 participants
participants (3)
-
Daniel Bevenius (JIRA) -
Kevin Conner (JIRA)
-
Stefano Maestri (JIRA)