[jira] [Commented] (AXIS2-2883) CLOSE_WAIT slowly building up over the period of time.

["Carusyte (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AXIS2-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092669#comment-13092669 ] 

Carusyte commented on AXIS2-2883:
---------------------------------

I'd like to propose a workaround here, it's been put into production and no further issue is reported yet. Since I'm not yet familiar with the entire Axis2 internals I am not sure if i can hack the source code. Hope this helps.

public class AxisOperationClientInvoker implements
		IServiceInvoker<SOAPEnvelope, SOAPEnvelope> {

	private IOptionsConfigurator configurator = null;
	private ConfigurationContext configContext = null;
	private ServiceClient serviceClient = null;

	public AxisOperationClientInvoker() throws AxisFault {
		configurator = ServiceClientRegistry.getConfigurator();
		configContext = ConfigurationContextFactory
				.createConfigurationContextFromFileSystem(null, null);
		serviceClient = new ServiceClient(configContext, null);

		// set AUTO_OPERATION_CLEANUP to false so that last http method resource
		// won't be incorrectly cleaned-up in concurrency. But UESR-CONTROL
		// SHOULD BE IMPOSED.
		serviceClient.getOptions().setProperty(
				ServiceClient.AUTO_OPERATION_CLEANUP, false);
	}

	@Override
	public SOAPEnvelope invokeService(SOAPEnvelope request, Object identifier)
			throws AxisFault {
		OperationClient operationClient = serviceClient
				.createClient(ServiceClient.ANON_OUT_IN_OP);

		MessageContext outMsgCtx = new MessageContext();

		outMsgCtx.setEnvelope(request);

		operationClient.addMessageContext(outMsgCtx);

		Options opts = operationClient.getOptions();
		opts.setProperty(IServiceConstants.IDENTIFIER, identifier);
		configurator.config(opts);
		initConfigurationContext(opts);

		SOAPEnvelope response = null;
		MessageContext inMsgCtx = null;
		try {
			operationClient.execute(true);
			inMsgCtx = operationClient.getMessageContext("In");
			response = getResponse(inMsgCtx);
		} catch (UnsupportedEncodingException e) {
			AxisFault.makeFault(e);
		} catch (XMLStreamException e) {
			AxisFault.makeFault(e);
		} finally {
			cleanupHttpResource(outMsgCtx);
		}

		return response;
	}

	private void initConfigurationContext(Options opts) {
		configContext.setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
				opts.getProperty(HTTPConstants.CACHED_HTTP_CLIENT));
	}

	private String getCharset(MessageContext msgCtx) {
		String charset = (String) msgCtx
				.getProperty(Constants.Configuration.CHARACTER_SET_ENCODING);
		if (charset == null || !Charset.isSupported(charset))
			charset = Charset.defaultCharset().name();
		return charset;
	}

	/**
	 * <b>VERY IMPORTANT:</b>clean up HTTP related resource，such as connection; so that
	 * the connection pool won't be starved. 
	 *
	 * @param msgCtx
	 * @throws AxisFault
	 */
	private void cleanupHttpResource(MessageContext msgCtx) throws AxisFault {
		msgCtx.getTransportOut().getSender().cleanup(msgCtx);
	}

	/**
	 * We need to make a new SOAPEnvelope instance out of the original in MessageContext, 
	 * and this new instance is in essence using a new ByteArrayInputStream; This way the 
	 * original stream can then be safely closed when HttpConnection is recollected in a 
	 * clean-up process, otherwise the Axiom deferred-parsing will break. This workaround
	 * may induce some unnecessary performance drawback.
	 * 
	 * @param msgCtx
	 * @return
	 * @throws UnsupportedEncodingException
	 * @throws XMLStreamException
	 */
	private SOAPEnvelope getResponse(MessageContext msgCtx)
			throws UnsupportedEncodingException, XMLStreamException {

		String charset = getCharset(msgCtx);

		SOAPEnvelope response = msgCtx.getEnvelope();

		InputStream is = new ByteArrayInputStream(response
				.toStringWithConsume().getBytes(charset));
		StAXBuilder newBuilder = BuilderUtil.getSOAPBuilder(is, charset);

		return (SOAPEnvelope) newBuilder.getDocumentElement();
	}

}

> CLOSE_WAIT slowly building up over the period of time.
> ------------------------------------------------------
>
>                 Key: AXIS2-2883
>                 URL: https://issues.apache.org/jira/browse/AXIS2-2883
>             Project: 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: Glen Daniels
>            Priority: Critical
>             Fix For: 1.5.1
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org