[jbossws-issues] [JBoss JIRA] (JBWS-4088) Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF
Alessio Soldano (JIRA)
issues at jboss.org
Thu Aug 9 17:26:00 EDT 2018
[ https://issues.jboss.org/browse/JBWS-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13617316#comment-13617316 ]
Alessio Soldano commented on JBWS-4088:
---------------------------------------
This is actually a known issue of Apache CXF, which is currently being dealt with. CXF 3.2.5 introduced a Client.getContexts() method that returns an autocloseable object that allows getting req/res context and cleans them up in try-with blocks: https://github.com/apache/cxf/commit/6abad1864187457984b0dff2622eafb4b5df5305 . The context clear method also removes the current thread association with the current context.
It should hence be a user responsibility to either explicitly call clear() on the response context or get the context thought the afore mentioned Contexts mechanism, all before returning the client to the pool.
> 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
> Fix For: jbossws-cxf-5.2.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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
More information about the jbossws-issues
mailing list