axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Walton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AXIS2-4007) Axis2 1.4.1 client stub not freed
Date Wed, 05 Nov 2008 22:44:44 GMT

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

Jason Walton commented on AXIS2-4007:
-------------------------------------

Also interesting to note: ServiceClient's cleanup() method behaves very differently when createConfigCtx
is true than when it is false.  In my case, when I'm seeing this, I'm creating clients dynamically
inside an axis2 server with running services, so for me, I'll end up with createConfigCtx
being true, whereas if you try just a simple Java application that instantiates a stub and
tries to clean it up, the code path is completely different.

I rather suspect that in the server-side case, you can work around this in 1.4.1 by replacing:

    stub.cleanup();

With:

    stub._getServiceClient().cleanup();
    stub.cleanup();

I'll give that a try tonight, and see if it fixes my case.

> Axis2 1.4.1 client stub not freed
> ---------------------------------
>
>                 Key: AXIS2-4007
>                 URL: https://issues.apache.org/jira/browse/AXIS2-4007
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: client-api
>    Affects Versions: 1.4.1
>         Environment: Axis2 1.4.1
> jdk1.5.0_12
>            Reporter: Nanpeng Chen
>
> For Axis2 1.4.1, if I instantiate a new client stub for every web service request, the
stub is not freed. This was not happened with Axis2 1.2. For example, I modified Version service's
getVersion() to do following:
> 	public sample.axisversion.GetVersionResponse getVersion() throws ExceptionException0
{
> 		TestServiceStub stub = null;
> 		try {
> 			stub = new TestServiceStub("http://localhost:8080/axis2_141/services/TestService/");
> 			HelloResponse response = stub.Hello(new HelloRequest("myName"));
> 		} catch (AxisFault e) {
> 			System.err.println(e.getMessage());
> 		} catch (RemoteException e) {
> 			System.err.println(e.getMessage());
> 		} finally {
> 			if (stub != null) {
> 				try {
> 					stub.cleanup();
> 				} catch (AxisFault e) {
> 					System.err.println(e.getMessage());
> 				}
> 			}
> 		}
> 		GetVersionResponse response = new GetVersionResponse();
> 		response.set_return("1.4.1");
> 		return response;
> 	}
> Each time getVersion() is called, it creates a new instance of TestServiceStub, and uses
it to send out a HelloRequest. I put this modified Version.aar along with the TestService.aar
into axis2_141.war and deployed it to JBoss. After I sent multiple version requests to the
Version service, I saw significant memory leak for JBOSS.
> I also tried to keep an instance of the stub into a singleton class, and use the same
instance every time as following:
> 	public sample.axisversion.GetVersionResponse getVersion() throws ExceptionException0
{
> 		TestServiceStub stub = null;
> 		try {
> 			stub = TestServiceStubSingleton.INSTANCE.getStub("http://localhost:8080/axis2_141/services/TestService/");
> 			HelloResponse response = stub.Hello(new HelloRequest("myName"));
> 		} catch (AxisFault e) {
> 			System.err.println(e.getMessage());
> 		} catch (RemoteException e) {
> 			System.err.println(e.getMessage());
> 		}
> 		GetVersionResponse response = new GetVersionResponse();
> 		response.set_return("1.4.1");
> 		return response;
> 	}
> This workaround fixed the memory leak. But in our applications, we have situations that
new client stub has to be created each time. I think the better solution is for Axis2 to free
the client stub.

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


Mime
View raw message