Facundo Velazquez created CXF-7710:
--------------------------------------
Summary: 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
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)
