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, 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
(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.
-
You can reply to this email to add a comment to the issue online.
