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

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
            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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

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

Lakshmanan Venkatachalam commented on AXIS2-2883:
-------------------------------------------------

Kindly ignore ServiceClient=null in the finally  block on the code attached in the bug description. That was not on the deployed code.

This was tried as work around for the problem.

thanks
Lakshmanan

> 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
>            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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

     [ https://issues.apache.org/jira/browse/AXIS2-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davanum Srinivas updated AXIS2-2883:
------------------------------------

    Assignee: Davanum Srinivas

> 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: Davanum Srinivas
>            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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

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

SomaSekharaReddy.K commented on AXIS2-2883:
-------------------------------------------

This problem is exists even in Axis 1.3. i am getting CLOSE_WAIT's even after invoking serviceclient.cleanupTransport()

> 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: Davanum Srinivas
>            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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

     [ https://issues.apache.org/jira/browse/AXIS2-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davanum Srinivas updated AXIS2-2883:
------------------------------------

    Assignee:     (was: Davanum Srinivas)

> 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
>            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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

     [ https://issues.apache.org/jira/browse/AXIS2-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Deepal Jayasinghe reassigned AXIS2-2883:
----------------------------------------

    Assignee: Deepal Jayasinghe

> 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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

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

Daniele Fiorellino commented on AXIS2-2883:
-------------------------------------------

Hi.

I've same problem.

Environment:  Operating System : Linux Red Hat Enterprise 4 Update 5
Axis2 Version : 1.2
Application Server : ApacheTomcat 5.5
Tomcat Version: Apache Tomcat 5.5.23
JVM Version: 1.6.0_02-b05
OS Vers: Linux 2.6.9-55.0.6.ELsmp i386

Have you news?
Bye.
DF

> 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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

    [ 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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

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

Najati Imam commented on AXIS2-2883:
------------------------------------

Thanks for the update! I have a couple of hopefully easy questions to give us users some idea about how to proceed :-)

 - Is there any time frame for the next release?
 - Are there any tolerable hacks to tide us over?
 - System.gc() has been mentioned but doesn't necessarily clean the connection up, right? The vm can choose to ignore the "hint"?

Thanks again :-)

> 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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

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

najati edited comment on AXIS2-2883 at 1/2/08 11:07 AM:
-------------------------------------------------------------

Thanks for the update! I have a couple of hopefully easy questions to give us users some idea about how to proceed :-)

 - Is there any time frame for the next release?
 - Are there any tolerable hacks to tide us over?
 - System.gc() has been mentioned but doesn't necessarily clean the connection up, right? The vm can choose to ignore the "hint"?

Thanks again :-)

(EDIT: I hope this isn't too close to user support. If it is I apologize.)

      was (Author: najati):
    Thanks for the update! I have a couple of hopefully easy questions to give us users some idea about how to proceed :-)

 - Is there any time frame for the next release?
 - Are there any tolerable hacks to tide us over?
 - System.gc() has been mentioned but doesn't necessarily clean the connection up, right? The vm can choose to ignore the "hint"?

Thanks again :-)
 

> 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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

[SomaSekharaReddy.K]

Hello,

I have a work around here. You can avoid CLOSE_Wait's if you use Http
1.0 instead of Http 1.1 protocol at Service client. We have faced this
problem earlier. After using Http 1.0, this problem is not occurred and
our systems are stable with out CLOSE_WAIT's from last three months.

Thanks and Regards
SomaSekharaReddy.K

-----Original Message-----
From: Najati Imam (JIRA) [mailto:jira@...]
Sent: Wednesday, January 02, 2008 11:09 AM
To: Kesara, Soma Sekhara Reddy
Subject: [jira] Issue Comment Edited: (AXIS2-2883) CLOSE_WAIT slowly
building up over the period of time.


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

najati edited comment on AXIS2-2883 at 1/2/08 11:07 AM:
-------------------------------------------------------------

Thanks for the update! I have a couple of hopefully easy questions to
give us users some idea about how to proceed :-)

 - Is there any time frame for the next release?
 - Are there any tolerable hacks to tide us over?
 - System.gc() has been mentioned but doesn't necessarily clean the
connection up, right? The vm can choose to ignore the "hint"?

Thanks again :-)

(EDIT: I hope this isn't too close to user support. If it is I
apologize.)

      was (Author: najati):
    Thanks for the update! I have a couple of hopefully easy questions
to give us users some idea about how to proceed :-)

 - Is there any time frame for the next release?
 - Are there any tolerable hacks to tide us over?
 - System.gc() has been mentioned but doesn't necessarily clean the
connection up, right? The vm can choose to ignore the "hint"?

Thanks again :-)
 

> 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.CHU
NKED,
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.



Notice:  All email and instant messages (including attachments) sent to
or from Franklin Templeton Investments (FTI) personnel may be retained,
monitored and/or reviewed by FTI and its agents, or authorized
law enforcement personnel, without further notice or consent.


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

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

SomaSekharaReddy.K commented on AXIS2-2883:
-------------------------------------------

Hello,

I have a work around here. You can avoid CLOSE_Wait's if you use Http
1.0 instead of Http 1.1 protocol at Service client. We have faced this
problem earlier. After using Http 1.0, this problem is not occurred and
our systems are stable with out CLOSE_WAIT's from last three months.

Thanks and Regards
SomaSekharaReddy.K

> 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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

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

Michele Mazzucco commented on AXIS2-2883:
-----------------------------------------

Indeed I was wrong... it happens on Mac OS as well. The workaround is to keep a reference to the connection manager and force it to close idle/stale connections.

> 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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

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

Michael Mathers commented on AXIS2-2883:
----------------------------------------

Michele said:  "I think this bug should be fixed ASAP."


Indeed.  This critical issue is now 10 months old.

> 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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

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

Michele Mazzucco commented on AXIS2-2883:
-----------------------------------------

Michael, in my previous comment I've also said that there's a workaround.

> 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: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

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

Chi Chi commented on AXIS2-2883:
--------------------------------

Hello

I am experiencing a similar issue. I have upgraded from Axis2 v1.3 to Axis2 v.1.4.1, in the hope of fixing this issue that way, but to no avail.

Can anyone help? I note there is a workaround listed above:

"The workaround is to keep a reference to the connection manager and force it to close idle/stale connections. "

However, I am not sure how I would go about doing this - can someone please post an example?

Other than the above is there any other solution?

Thanks
Chi Chi

> 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.

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

Michael Mathers commented on AXIS2-2883:
----------------------------------------


System.gc() works for me in the meantime.  It may or may not work for
you.

Michael
 

> 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.

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

Chi Chi commented on AXIS2-2883:
--------------------------------

Michael, thanks for your response!

I think, in fact, my problem is slightly different from the original one posted. I am working on a high load application, calling a webservice approximately every second! I am currently doing a performance test and the number of CLOSE_WAITs rises gradually over the course of the test.

I therefore do not think calling System.gc() is an option, certainly not EVERY time a webservice is called! For the moment I will have to leave this to the JVM.

So, does anyone actually know what the problem is? Is it due to failed service calls (eg - AxisFaults) or successful calls? Why does garbage collecting fix it? Presumably there is something called from the finalize method on the stub object? Can this not be called manually?

Back to the workaround:

"The workaround is to keep a reference to the connection manager and force it to close idle/stale connections. "

Does anyone know how I would go about implementing this change?

Thanks
Jay

> 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.

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

Michael Mathers commented on AXIS2-2883:
----------------------------------------


I don't run it on every call either.  I keep a count and execute after a
certain number of times.  I am not on a high load application though so
I have freedom that you do not.   I am on Axis2 1.1 and it's dismaying
to me that this is not fixed yet even though it appears someone knows
exactly what to do about it (see Michele's comments).

> 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.

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

Rigadon commented on AXIS2-2883:
--------------------------------

Micheal, thanks again for your response!

https://issues.apache.org/jira/browse/AXIS2-935

This is basically the same issue and needs fixing.

> 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.