]
Jim Ma updated JBWS-4088:
-------------------------
Fix Version/s: jbossws-cxf-5.4.2.Final
(was: jbossws-cxf-5.4.1.Final)
Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to
prevent memory leak in CXF
---------------------------------------------------------------------------------------------
Key: JBWS-4088
URL:
https://issues.redhat.com/browse/JBWS-4088
Project: JBoss Web Services
Issue Type: Enhancement
Reporter: David Boeren
Priority: Minor
Fix For: jbossws-cxf-5.4.2.Final
I think the explanation comes from the way the response context is kept within the
ClientImpl. The ClientImpl has the following:
protected Map<Thread, Map<String, Object>> responseContext =
Collections.synchronizedMap(new WeakHashMap<Thread, Map<String, Object>>());
and the getResponseContext() is implemented this way:
public Map<String, Object> getResponseContext() {
if (!responseContext.containsKey(Thread.currentThread())) {
responseContext.put(Thread.currentThread(), new HashMap<String,
Object>());
}
return responseContext.get(Thread.currentThread());
}
Now, in the customer case, I believe the threads that serve as keys to the weak hashmap
are never GCed (perhaps because they simply come from a thread pool that reuses them) and
I don't see the response context being explicitly cleaned up in cxf except when the
clientimpl is destroyed (which does not happen often in customer case as the clients are
pooled).
I would suggest to try explicitly cleaning up the response message context contents.
The customer has successfully done this using this on their client side:
dispatcher.getResponseContext().remove("org.apache.cxf.staxutils.W3CDOMStreamWriter");
Is it possible to have this fix added to JBossWS as an enhancement? Full details are on
the case link.