[
https://issues.apache.org/jira/browse/AXIS2-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555249#action_12555249
]
David Poon commented on AXIS2-2883:
-----------------------------------
We are in development to replace the use of jax-rpc with Axis2 for (j2ee)
clients to invoke services. Our workload is thousands of concurrent users
making thousands of service client calls. So we are interested in having this
issue resolved. I have read these interrelated jira cases:
https://issues.apache.org/jira/browse/AXIS2-2593
https://issues.apache.org/jira/browse/AXIS2-935
https://issues.apache.org/jira/browse/AXIS2-2883
https://issues.apache.org/jira/browse/AXIS2-2724
Whilst the issue is still unresolved, we are hoping to investigate at least one
of the following workaround options under v1.3 of Axis2.
Option 1 - Use http v1.0 rather than v1.1
Option 2 - Create a new HttpClient for each client service operation call
Option 3 - One HttpClient shared by all service clients
Under option 2, we will instantiate a separate HttpClient for each service
operation invocation. We link the HttpClient and service client instance by
using the HTTPConstants.REUSE_HTTP_CLIENT and HTTPConstants.CACHED_HTTP_CLIENT
options. Our client code will hold on to the reference to the HttpClient so
that when the service operation is completed, we can get access to the Http
Connection Manager (HCM) from the HttpClient. Once we got the HCM, we call its
shutdown() method - which should close down all the connections in the
underlying connection pool maintained bythe HCM.
Option 2 is essentially what Axis2 does by default (new HttpClient for every
client service operation call). The difference is that under the Axis2 default
behaviour, there is nothing to trigger the call to the HCM's shutdown() method.
(Other "cleanup" methods are called, but as suggested by afore-mentioned jira
cases, these other clean up methods ultimately does not close down the
connections because under the http v1.1 protocol, they are keep "in waiting' in
case they are reused - but they never are anyway under the Axis2 default
behavior.)
Another interesting difference is that in the Axis2
AbstractHTTPSender.getHttpClient() method, we see that it does *not* bother to
call its initializeTimeouts(msgContext, httpClient) method if it is reusing a
HttpClient specified through the HTTPConstants.REUSE_HTTP_CLIENT and
HTTPConstants.CACHED_HTTP_CLIENT options - so under option 2, we will have to
write our own code to set the timeouts.
With option 3, we will create a HttpClient and configure its HCM pool size etc
to cater for our expected workload. This HttpClient is then set into the
ConfigurationContext instance that is shared by all service clients (actaully
we use the wsdl-to-java generated Stubs). On application shutdown, we will call
the HCM's shutdown() method.
We are *not* using https, so option 2 will probably suffice for us.
I found the following Axis2 code useful and "interesting"...
public abstract class AbstractHTTPSender {
...
protected HttpClient getHttpClient(MessageContext msgContext) {
HttpClient httpClient;
Object reuse =
msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
if (reuse == null) {
reuse =
msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
}
if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
httpClient = (HttpClient)
msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
if (httpClient == null) {
httpClient = (HttpClient) msgContext.getConfigurationContext()
.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
if (httpClient != null)
return httpClient;
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connectionManager);
msgContext.getConfigurationContext()
.setProperty(HTTPConstants.CACHED_HTTP_CLIENT, httpClient);
} else {
HttpConnectionManager connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
if(connManager != null){
httpClient = new HttpClient(connManager);
} else {
//Multi threaded http connection manager has set as the default
connManager = new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connManager);
}
}
// Get the timeout values set in the runtime
initializeTimeouts(msgContext, httpClient);
return httpClient;
}
...
======
public class HTTPSender extends AbstractHTTPSender {
...
private void sendViaPost(MessageContext msgContext, URL url,
String soapActionString) throws AxisFault {
HttpClient httpClient = getHttpClient(msgContext);
....
try {
executeMethod(httpClient, msgContext, url, postMethod);
handleResponse(msgContext, postMethod);
} catch (IOException e) {
log.info("Unable to sendViaPost to url[" + url + "]", e);
throw AxisFault.makeFault(e);
} finally {
cleanup(msgContext, postMethod);
}
}
=====
private void cleanup(MessageContext msgContext, HttpMethod method) {
if (msgContext.isPropertyTrue(HTTPConstants.AUTO_RELEASE_CONNECTION)) {
method.releaseConnection();
}
}
=====
The use of HTTPConstants.AUTO_RELEASE_CONNECTION is only relevant for
*asynchronous* service operation calls, so that does not help us.
> CLOSE_WAIT slowly building up over the period of time.
> ------------------------------------------------------
>
> Key: AXIS2-2883
> URL: https://issues.apache.org/jira/browse/AXIS2-2883
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: client-api
> Affects Versions: 1.1
> Environment: Operating System : Solaris
> Axis2 Version : 1.1
> Application Server : weblogic 8.1 SP6
> Using with Cocoon and weblogic DSP
> Reporter: Lakshmanan Venkatachalam
> Assignee: Deepal Jayasinghe
> Priority: Critical
>
> I am experiencing theconstant increase in close wait in the production
> environment over the period 7 days.
> We are using Synchronous webservices and we are calling two webservices 24
> times every day. We have allocated the maximum of 1.5 GB per application
> instance and we have two application instances. We are utilizing maximum of
> 250 - 300 MB in average. So Full GC never runs in our environment.
> It seems like the client API ServiceClient.java is not cleaning up the
> resources associated with this component. We are creating the new
> ServiceClient component on every call we have for webservices. Though we have
> called the cleanup() method at the end of every call to the webservices. At
> times its not getting executed.
> But when we force garabage collection from the application, it was able to
> clear all the CLOSE_WAIT components. Since we have similar cleanup() call on
> finalize() method, it is able to do proper clean up when GC is collecting
> these objects.
> Forcing GC cannot be a solution, I like to hear from axis2 experts on how we
> can resolve this problem properly and what could be the cause for this
> happening.
> Below is our client code for your reference.
> private WebServiceResponse invokeWebservice(OMElement inputElement,
> Options options) throws WebServiceInvokerException {
> ServiceClient serviceClient = null;
> try {
> serviceClient = new ServiceClient();
> serviceClient.setOptions(options);
> // This following line of code is used when we are using
> // WS-Addressing. User has to make sure the addressing
> MAR file in
> // class path before enable the following line of code
> //
> // serviceClient.engageModule(new QName(
> // org.apache.axis2.Constants.MODULE_ADDRESSING));
> // Invoking synchrounous webservice
> //
> OMElement result =
> serviceClient.sendReceive(inputElement);
>
> OMNode firstOMChild = result.getFirstOMChild();
> // Conver the OMelements to XML String
> //
> Writer stringWriter = new StringWriter();
> firstOMChild.serialize(stringWriter);
> serviceClient.cleanup();
> stringWriter.flush();
> // Return the Axis2WebserviceResponse
> //
> return new
> Axis2WebServiceResponse(stringWriter.toString());
> } catch (AxisFault afe) {
> throw new WebServiceInvokerException(afe);
> } catch (XMLStreamException xse) {
> throw new WebServiceInvokerException(xse);
> } catch (IOException ioe) {
> throw new WebServiceInvokerException(ioe);
> } finally {
> try {
> serviceClient.cleanup();
> serviceClient=null;
> } catch (AxisFault axisFault) {
> //
> }
> }
> }
> }
> options are:
> Options options = new Options();
> options.setTo(targetEPR);
> options.setUseSeparateListener(false);
> options.setAction(wsRequest.getAction());
> options.setTimeOutInMilliSeconds(600000);
> options.setTransportInProtocol("http");
>
> options.setProperty(org.apache.axis2.context.MessageContextConstants.CHUNKED,
> org.apache.axis2.transport.http.HTTPConstants.HEADER_TRANSFER_ENCODING);
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
