[jbossws-issues] [JBoss JIRA] (JBWS-4088) Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF

david.boeren (JIRA) issues at jboss.org
Wed Jan 17 12:30:00 EST 2018


david.boeren created JBWS-4088:
----------------------------------

             Summary: 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: Feature Request
            Reporter: david.boeren
            Priority: Minor
             Fix For: jbossws-cxf-5.2.1.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.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


More information about the jbossws-issues mailing list