TypeMappingImpl is not thread safe

• Key: AXIS-2498
• Type: Bug
• Status: Open
• Priority: Major
• Assignee: Unassigned
• Reporter: Manuel Mall
• Component/s: Serialization/Deserialization
• Affects Version/s: 1.4

Description

This issue originates from http://marc.theaimsgroup.com/?l=axis-user&m=114993403032512&w=2.

Original report and Cyrille's initial response below:

================================

   Hello Manuel,

   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
threadsafe.

   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
(classloader order).

PATCH DESCRIPTION
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

--
Cyrille Le Clerc
[e-mail]
[e-mail]
+33 6.61.33.69.86

On 6/10/06, Manuel Mall <[e-mail]> wrote:
> I am aware that this topic has been discussed a number of times, e.g.
> http://marc.theaimsgroup.com/?l=axis-user&m=113771126214607&w=2.
>
> 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
> call.
>
> 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
> this.
>
> Thanks
>
> Manuel
> -----
> "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.encoding.TypeMappingImpl.isRegistered(TypeMappingImpl.java:195)
> at
> org.apache.axis.encoding.TypeMappingDelegate.isRegistered(TypeMappingDelegate.java:136)
> at org.apache.axis.client.Call.registerTypeMapping(Call.java:2280)
> at org.apache.axis.client.Call.registerTypeMapping(Call.java:2322)
> at
> au.com.anstat.oscar.landata.webservices.externalwsdl.Portal_340Stub.createCall(Portal_340Stub.java:2494)
> - locked <0x91cb2dc8> (a
> au.com.anstat.oscar.landata.webservices.externalwsdl.Portal_340Stub)
> at
> au.com.anstat.oscar.landata.webservices.externalwsdl.Portal_340Stub.propertyCertificateList(Portal_340Stub.java:3979)
> at
> au.com.anstat.oscar.common.landata.Operation.doPropertyCertificateList(Operation.java:574)
>