axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ram Lakshmanan (JIRA)" <>
Subject [jira] Created: (AXIS-2816) reuse of ServiceLocator causes Inifnite Loop, CPU Spike
Date Mon, 28 Dec 2009 21:08:30 GMT
reuse of ServiceLocator causes Inifnite Loop, CPU Spike

                 Key: AXIS-2816
             Project: Axis
          Issue Type: Bug
          Components: Basic Architecture
    Affects Versions: 1.2RC3, 1.2, 1.2.1, 1.3, 1.4, 1.5
         Environment: Any Multi-core CPU Systems.
            Reporter: Ram Lakshmanan

In our application we use Axis 1.2/Java 1.6 as SOAP client (but problem persist even in Axis
1.4 as well). According to community recommendation (
we create Stub object for each request and reuse the same ServiceLocator object across all
requests. We are using the same ServiceLocator so that we can reuse the connections in the
Commons HTTP Client pool and take advantage of Persistent HTTP 1.1 connections, it gives good
performance improvement especially in mutual-auth SSL communications. In client-config.wsdd
we have setup to use CommonsHTTPSender for HTTP transport:

<transport name="http" pivot="java:org.apache.axis.transport.http.CommonsHTTPSender"/>

In this setup Axis goes on an infinite loop, since TypeMappingImpl which is of type java.util.HashMap
is not thread safe. It's sad to see unsafe usage of HashMap results in infinite looping rather
than exceptions or wrong data.  

Following thread-dump excerpt shows the thread to be spinning for ever:

"common-sor-wrapper-pool-9" daemon prio=10 tid=038f7cb0 nid=30622 lwp_id=4750978 runnable
   java.lang.Thread.State: RUNNABLE
	at java.util.HashMap.put(
	at org.apache.axis.encoding.TypeMappingImpl.internalRegister(
	at org.apache.axis.encoding.TypeMappingImpl.register(
	at org.apache.axis.encoding.TypeMappingDelegate.register(
	at org.apache.axis.client.Call.registerTypeMapping(
	at org.apache.axis.client.Call.registerTypeMapping(
In order to address this problem 

 1. we are now instantiating ServiceLocator object for each request.
 2. Enhanced CommonsHTTPSender and made HttpConnectionManager as singleton (i.e. static),
earlier it was created for each and every instantiation of ServiceLocator object. So now enhanced
CommonsHTTPSender would look like:

    private static  HttpConnectionManager connectionManager;
    private static CommonsHTTPClientProperties clientProperties;
    private static boolean initialized = false;
    public CommonsHTTPSender() {
        if (!initialized) {

    private synchronized static void initialize() {
        if (!initialized) {
            MultiThreadedHttpConnectionManager cm = new MultiThreadedHttpConnectionManager();
            clientProperties = CommonsHTTPClientPropertiesFactory.create();
            // If defined, set the default timeouts
            // Can be overridden by the MessageContext
            connectionManager = cm;
            initialized = true;
    Earlier it used to look like:
    private HttpConnectionManager connectionManager;
    private CommonsHTTPClientProperties clientProperties;
    public CommonsHTTPSender() {
        MultiThreadedHttpConnectionManager cm = new MultiThreadedHttpConnectionManager();
        this.clientProperties = CommonsHTTPClientPropertiesFactory.create();
        this.connectionManager = cm;

Fix works fine with out any problems. The same problem is documented in this defect:
- But it's not clear whether proposed patch address the problem completely.

We are looking forward to see hear anyone else has faced the similar problem, if so how problem
was resolved.

Thank you.

Ram Lakshmanan

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message