[ https://issues.apache.org/jira/browse/CXF-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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 (v7.6.3#76005)