Uploaded image for project: 'Axis'
  1. Axis
  2. AXIS-2816

reuse of ServiceLocator causes Inifnite Loop, CPU Spike

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 1.2RC3, 1.2, 1.2.1, 1.3, 1.4, old-trunk
    • None
    • Basic Architecture
    • Any Multi-core CPU Systems.

    Description

      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 (http://wiki.apache.org/ws/FrontPage/Axis/AxisCommonsHTTP) 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 [693ff000..69400d10]
      java.lang.Thread.State: RUNNABLE
      at java.util.HashMap.put(HashMap.java:374)
      at org.apache.axis.encoding.TypeMappingImpl.internalRegister(TypeMappingImpl.java:259)
      at org.apache.axis.encoding.TypeMappingImpl.register(TypeMappingImpl.java:216)
      at org.apache.axis.encoding.TypeMappingDelegate.register(TypeMappingDelegate.java:73)
      at org.apache.axis.client.Call.registerTypeMapping(Call.java:2255)
      at org.apache.axis.client.Call.registerTypeMapping(Call.java:2292)

      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)

      { initialize(); }

      }

      private synchronized static void initialize() {
      if (!initialized)

      { MultiThreadedHttpConnectionManager cm = new MultiThreadedHttpConnectionManager(); clientProperties = CommonsHTTPClientPropertiesFactory.create(); cm.getParams().setDefaultMaxConnectionsPerHost(clientProperties.getMaximumConnectionsPerHost()); cm.getParams().setMaxTotalConnections(clientProperties.getMaximumTotalConnections()); // 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(); cm.setMaxConnectionsPerHost(clientProperties.getMaximumConnectionsPerHost()); cm.setMaxTotalConnections(clientProperties.getMaximumTotalConnections()); this.connectionManager = cm; }

      Fix works fine with out any problems. The same problem is documented in this defect: https://issues.apache.org/jira/browse/AXIS-2498 - 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

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              ootechnology Ram Lakshmanan
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: