[
https://issues.apache.org/jira/browse/AXIS-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen updated AXIS-2816:
----------------------------------
Labels: thread-safety (was: )
> reuse of ServiceLocator causes Inifnite Loop, CPU Spike
> -------------------------------------------------------
>
> Key: AXIS-2816
> URL: https://issues.apache.org/jira/browse/AXIS-2816
> Project: Axis
> Issue Type: Bug
> Components: Basic Architecture
> Affects Versions: 1.2RC3, 1.2, 1.2.1, 1.3, 1.4, old-trunk
> Environment: Any Multi-core CPU Systems.
> Reporter: Ram Lakshmanan
> Labels: thread-safety
>
> 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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
