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 [EMAIL PROTECTED] [EMAIL PROTECTED] +33 6.61.33.69.86 On 6/10/06, Manuel Mall <[EMAIL PROTECTED]> 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) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
axis-1.4-threadSafetyPatch.jar
Description: application/java-archive
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
