From Alessio, we only need to add some case for this jira.

Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF --------------------------------------------------------------------------------------------- Key: JBWS-4088 URL: https://issues.jboss.org/browse/JBWS-4088 Project: JBoss Web Services Issue Type: Enhancement Reporter: David Boeren Priority: Minor 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.