memory leak from ws security

[glassfishrobot]

This issue was discovered while performing leak testing using JProbe 8.1. The
leak is from security classes that are allocated from using a WebServiceRef in
an EJB or servlet. The leak can be partially cleanup up by calling the close
method of the Closeable interface of the port type, but this is only a
documented feature of the Reliable Messaging handling. This has been discussed
with Vbkumar.Jayanti@Sun.COM. I have created a test case that uses a servlet
to trigger the leak (https://localhost:8181/MetroLeakTest/test?LEAK=no, or
LEAK=yes) will either call the close method, or not. The servlet class must be
updated with the correct constants for the local server.

Environment

Operating System: All
Platform: All

Affected Versions

[2.0]

[glassfishrobot]

Reported by geturnerlmco@java.net

[glassfishrobot]

Was assigned to kumarjayanti@java.net

[glassfishrobot]

geturnerlmco@java.net said:
Created an attachment (id=1022)
EAR source to show wss leak

[glassfishrobot]

File: MetroLeakTest.zip
Attached By: geturnerlmco@java.net

[glassfishrobot]

kumarjayanti@java.net said:
reassign

[glassfishrobot]

kumarjayanti@java.net said:
While i am working on the fix, as indicated in the bug report :

calling ((com.sun.xml.ws.Closeable)proxy).close() once you are done with the
Proxy is a workaround for this problem.

[glassfishrobot]

kumarjayanti@java.net said:
The possible solutions for this bug will be discussed on 5th Nov, thursday in
Tango Tech meeting. I have been asked in the meanwhile to update this bug in
view of Nov 3rd HCF. The priority will be brought back to original post Nov 3rd.

[glassfishrobot]

kumarjayanti@java.net said:
cleaned up the code to not use a tube reference as the key to the hashmap. Made use of weakreferences at
a few other places.

[glassfishrobot]

kumarjayanti@java.net said:
cleaned up the code to not use a tube reference as the key to the hashmap. Made use of weakreferences at
a few other places.

[glassfishrobot]

Marked as fixed on Sunday, October 3rd 2010, 5:57:10 pm

[glassfishrobot]

wap said:
I think, this issue is not fixed. Neither in version 2.1 nor in 2.1.1 the memory is cleaned up correctly without the workaround invoking close() explicitly. The hashtable in the IssuedTokenManager remains growing until the OOME occurs.

The workaround has a another issue, which comes up, if close fails de to violation of the security policy, e.g. clock skew to big, an exception occurs, before the token manager could be cleaned. In this case, the memory continues growing, and I even saw some input streams remaining open and a blocking thread.

I think, close() has to handle such situations and clean up, as I do not see any chance to recover from that situation. Even better, as the OP suggests, the usage of close() should be entirely unnecessary.

[glassfishrobot]

File: thread-dump-filtered.txt
Attached By: wap

[glassfishrobot]

wap said:
A stuck thread that waits forever on an input stream.

[glassfishrobot]

wap said:
The leak is fixed for me in Metro 2.2-b13. However, the workaround with invocation of Closable.close() throws an NPE now. But this is only a very minor issues, as the client should not invoke it at all.

[glassfishrobot]

nitkal said:
Could you please provide the stack trace ? Also would the previously attached test case help to reproduce the error?

Thanks
Nithya

[glassfishrobot]

geturnerlmco said:
There was no stack trace, it was a memory leak. All of the information to reproduce the problem is in the original filing. Thanks.

[glassfishrobot]

@vbkumarjayanti said:
You mentioned the workaround with invocation of Closable.close() throws an NPE now, so we are asking what is the stack trace. Otherwise we understand the issue is fixed ?.

[glassfishrobot]

This issue was imported from java.net JIRA WSIT-1260