[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
