Facundo Velazquez updated CXF-7710:
    Attachment: heapdump_Leak_Suspects.zip

> 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

Reply via email to