[
https://issues.apache.org/jira/browse/CXF-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454829#comment-16454829
]
ASF GitHub Bot commented on CXF-7710:
-------------------------------------
fsgonz commented on issue #409: CXF-7710: ClientImpl is memory-leak prone
URL: https://github.com/apache/cxf/pull/409#issuecomment-384780055
I am taking the issue from @facundovs and I was reviewing the fix introduced
in CXF-7591 as @dkulp mentioned. At first I thought that that may provide the
users with a way to clear the context using: getResponseContext().clear() (as
you said) , but I find that in every case where responseContext.put is used the
clear method is not overridden so the when I invoke
client.getResponseContext().clear(), the map associated to the thread key is
removed but not the the entry with the thread.
In the case where a ThreadPool is used, a WeakHashMap will make no
difference.
Shouldn't the clear method of the hashmap always be overridden? For example
here:
https://github.com/apache/cxf/blob/1396f046333108ec0e7819bf4de154505ff4564c/core/src/main/java/org/apache/cxf/endpoint/ClientImpl.java#L338
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> ClientImpl is memory-leak prone
> -------------------------------
>
> Key: CXF-7710
> URL: https://issues.apache.org/jira/browse/CXF-7710
> Project: CXF
> Issue Type: Bug
> Reporter: Facundo Velazquez
> Priority: Critical
> Attachments: heapdump_Leak_Suspects.zip, leak capture.png
>
>
> In the Mule ESB we are seeing a memory leak caused by non-released objects in
> the
> org.apache.cxf.endpoint.ClientImpl.
> After some research, I could see that the requestContext and the
> responseContext have a thread local implementation. As our code calls the
> client from different threads, in a high load scenario, lots of entries will
> be put in the requestContext map. Take into account that we clean each
> requestContext value (that is an EchoContext object), but an entry per thread
> is kept alive in the requestContext map (with an empty EchoContext map).
> You'll able to see in the attached files that this is causing a memory leak.
> Even in my tests trying to reproduce the issue, I've obtained a fatal
> OutOfMemoryError.
> Looking at the code, I've seen that the request context is a WeakHashMap,
> however the keys are threads. I supposed the purpose of this implementation
> is that entries can be removed when necessary by the garbage collector.
> However, if the threads are pooled (which is our case), strong references
> will be pointing to them, and will be never collected.
> I suppose an easy solution could be to use the thread names as keys instead
> threads objects directly. If this approach is taken, consider using string
> constructors to wrap the literal name for ensuring its garbage collection
> (since this is another well-know issue -->
> [https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how|https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how).]
> ).
> Another solution, that entails more changes, would be to use a Guava Cache,
> setting an expiration time.
> If the first approach is implemented, could you provide a way to clean the
> requestContext programmatically?, so in this way, we don't have to depend on
> the garbage collection process.
> Thank you very much.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
