This issue originates from http://marc.theaimsgroup.com/?l=axis-user&m=114993403032512&w=2.
Original report and Cyrille's initial response below:
My understanding is the Stub#createCall invokes methods on an
instance of TypeMapping that is shared by the AxisEngine via the
TypeMappingRegistry. Unfortunately, this TypeMappingImpl is not
Here is a a draft patch that should fix it waiting for an official
patch. Note that I didn't succeed in reproducing the deadlock, I
patched according to my understanding of the problem.
Moreover, I preferred to send you this draft/emergency patch before
doing extensive testings. It works on my samples but I didn't look at
the impact on performances (it should be limited ).
HOW TO US THIS PATCH ?
Here is a draft patch to fix this issue. To use it, the easiest way
is to unzip axis-1.4-threadSafetyPatch.jar under /WEB-INF/classes
TypeMappingImpl.java is the only modified class. Modifications:
- use synchronized maps instead of plain HashMaps
- synchronize internalRegister() method to ensure atomicity of access
to maps in modification
- synchronize access to "namespaces" variable in setSupportedEncodings
to ensure atomicity of the clear-add sequence
Hope this helps,
Cyrille Le Clerc
On 6/10/06, Manuel Mall <email@example.com> wrote:
> I am aware that this topic has been discussed a number of times, e.g.
> I followed the advice that the locator is thread safe but the stub is
> not and as I have only stateless calls I have therefore a single
> instance of the serviceLocator and a new instance of the stub for each
> However, when I have many simultaneous client calls I get
> random "lock-ups" of the system. The threads always end up stuck in the
> same state, that is in a call to HashMap.containsKey (see below). The
> trace snippet is taken from a 'kill -3' output. There were around 20
> threads all with the identical trace. The only difference being the
> address in the '- locked <...> (a ...)' line, which is to be expected
> as I have separate instances of the stub.
> I had hoped that the fix to
> https://issues.apache.org/jira/browse/AXIS-2284 which is in Axis 1.4
> had addressed this issue. But even after switching to Axis 1.4 the
> problem remains. So it seems to me that there is another concurrent
> HashMap modification problem left in the Axis code in the area of the
> Type Mapping Registry.
> Needless to say that the problem only occurs on a multi CPU system.
> As I am really not familiar enough with the Axis internals I am
> wondering if anyone with more insight has a suggestion how to avoid
> "LandataWebPollRequestEventSlave:" prio=1 tid=0x8b48f0a0 nid=0x25cf
> runnable [0x8ac74000..0x8ac745f0]
> at java.util.HashMap.containsKey(HashMap.java:349)
> at java.util.HashMap$KeySet.contains(HashMap.java:873)
> at org.apache.axis.client.Call.registerTypeMapping(Call.java:2280)
> at org.apache.axis.client.Call.registerTypeMapping(Call.java:2322)
> - locked <0x91cb2dc8> (a
|Workflow||jira [ 12373686 ]||Default workflow, editable Closed status [ 12555199 ]|
|Workflow||Default workflow, editable Closed status [ 12555199 ]||jira [ 12578728 ]|