[JBoss JIRA] (JBWS-4088) Remove org.apache.cxf.staxutils.W3CDOMStreamWriter from context to prevent memory leak in CXF
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4088?page=com.atlassian.jira.plugin.... ]
Jim Ma updated JBWS-4088:
-------------------------
Fix Version/s: jbossws-cxf-5.3.1.Final
> 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.3.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.12.1#712002)
5 years, 6 months
[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
Jim Ma updated JBWS-4080:
-------------------------
Fix Version/s: jbossws-cxf-5.3.1.Final
(was: jbossws-cxf-5.3.0.Final)
> Unpublishing WSDL files takes very long (race condition?)
> ---------------------------------------------------------
>
> Key: JBWS-4080
> URL: https://issues.jboss.org/browse/JBWS-4080
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-5.1.5.Final, jbossws-cxf-5.1.6.Final, jbossws-cxf-5.1.7.Final, jbossws-cxf-5.1.8.Final, jbossws-cxf-5.1.9.Final
> Environment: Windows, Java 8, Wildfly 10.1
> Reporter: Stefan Moebius
> Priority: Major
> Fix For: jbossws-cxf-5.3.1.Final
>
> Attachments: jbossws-cxf-server-5.1.5.Final.jar
>
>
> The change done for JBWS-3992 causes shutdown of Wildfly 10.1 to take much longer, causing timeouts in the Windows service manager.
> The problem appears to be this:
> There is a pool of “MSC service threads”. These threads are responsible among other things for the publishing and also the unpublishing of web services, which involves the creation and also the deletion of WSDL files, using WSDLFilePublisher. These threads operate on deployment units, which means the JARs inside an EAR.
> The WSDL files are published in this structure:
> data/wsdl/Bar.ear/<Foo>.jar/, with one folder for each JAR that has WS.
> In jbossws-cxf-5.1.4, each of these threads would delete the files and the folder for one deployment unit, i.e. one JAR. The impact was that the root folder data/wsdl/Bar.ear/ would remain, which was reported as a JBWS-3992 and fixed in 5.1.5.
> The fixed, however, causes each thread to now traverse to the root deployment unit (Bar.ear) and recursively delete all files under data/wsdl/Bar.ear and the folder itself. The problem is that this causes multiple threads to attempt to delete the same tree of files in parallel, at least on Windows causing this to take ages.
> The change:
> [https://github.com/jbossws/jbossws-cxf/commit/162c9e4d44f9832de6b6147b3b9...]
> As a workaround, we've downgraded to 5.1.4, which made the issue go away.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (JBWS-4146) Intermittent NPE in jbossws-cxf-client unit tests with IBM JDK
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4146?page=com.atlassian.jira.plugin.... ]
Jim Ma updated JBWS-4146:
-------------------------
Fix Version/s: jbossws-cxf-5.3.1.Final
(was: jbossws-cxf-5.3.0.Final)
> Intermittent NPE in jbossws-cxf-client unit tests with IBM JDK
> --------------------------------------------------------------
>
> Key: JBWS-4146
> URL: https://issues.jboss.org/browse/JBWS-4146
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-5.2.3.Final
> Environment: IBM JDK
> Reporter: Jan Blizňák
> Priority: Major
> Fix For: jbossws-cxf-5.3.1.Final
>
>
> An intermittent NPE is thrown during building project on IBM JDK, might be specific issue with different JDK vendor but might be also revealing the bug in client code.
> When the situation occurs the exception is thrown in arbitrary call of org.apache.cxf.endpoint.Client#getEndpoint
> {code:java}
> ERROR!
> 15:43:15 java.lang.NullPointerException
> 15:43:15 at org.jboss.wsf.stack.cxf.client.configuration.CXFClientConfigurerTest.testAddInterceptorsThroughSetConfigProperties(CXFClientConfigurerTest.java:524)
> {code}
> Reproducibility ~ <5%
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
Jim Ma commented on JBWS-4080:
------------------------------
[~stmoebius] : I tried to fix this issue by add some synchronized block when unpublish wsdl. Can you please copy this patched jar (attached file) to wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/ws/cxf/jbossws-cxf-server/main/ and verify if this works ? Thanks.
> Unpublishing WSDL files takes very long (race condition?)
> ---------------------------------------------------------
>
> Key: JBWS-4080
> URL: https://issues.jboss.org/browse/JBWS-4080
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-5.1.5.Final, jbossws-cxf-5.1.6.Final, jbossws-cxf-5.1.7.Final, jbossws-cxf-5.1.8.Final, jbossws-cxf-5.1.9.Final
> Environment: Windows, Java 8, Wildfly 10.1
> Reporter: Stefan Moebius
> Priority: Major
> Fix For: jbossws-cxf-5.3.0.Final
>
> Attachments: jbossws-cxf-server-5.1.5.Final.jar
>
>
> The change done for JBWS-3992 causes shutdown of Wildfly 10.1 to take much longer, causing timeouts in the Windows service manager.
> The problem appears to be this:
> There is a pool of “MSC service threads”. These threads are responsible among other things for the publishing and also the unpublishing of web services, which involves the creation and also the deletion of WSDL files, using WSDLFilePublisher. These threads operate on deployment units, which means the JARs inside an EAR.
> The WSDL files are published in this structure:
> data/wsdl/Bar.ear/<Foo>.jar/, with one folder for each JAR that has WS.
> In jbossws-cxf-5.1.4, each of these threads would delete the files and the folder for one deployment unit, i.e. one JAR. The impact was that the root folder data/wsdl/Bar.ear/ would remain, which was reported as a JBWS-3992 and fixed in 5.1.5.
> The fixed, however, causes each thread to now traverse to the root deployment unit (Bar.ear) and recursively delete all files under data/wsdl/Bar.ear and the folder itself. The problem is that this causes multiple threads to attempt to delete the same tree of files in parallel, at least on Windows causing this to take ages.
> The change:
> [https://github.com/jbossws/jbossws-cxf/commit/162c9e4d44f9832de6b6147b3b9...]
> As a workaround, we've downgraded to 5.1.4, which made the issue go away.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (JBWS-4080) Unpublishing WSDL files takes very long (race condition?)
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4080?page=com.atlassian.jira.plugin.... ]
Jim Ma updated JBWS-4080:
-------------------------
Attachment: jbossws-cxf-server-5.1.5.Final.jar
> Unpublishing WSDL files takes very long (race condition?)
> ---------------------------------------------------------
>
> Key: JBWS-4080
> URL: https://issues.jboss.org/browse/JBWS-4080
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-5.1.5.Final, jbossws-cxf-5.1.6.Final, jbossws-cxf-5.1.7.Final, jbossws-cxf-5.1.8.Final, jbossws-cxf-5.1.9.Final
> Environment: Windows, Java 8, Wildfly 10.1
> Reporter: Stefan Moebius
> Priority: Major
> Fix For: jbossws-cxf-5.3.0.Final
>
> Attachments: jbossws-cxf-server-5.1.5.Final.jar
>
>
> The change done for JBWS-3992 causes shutdown of Wildfly 10.1 to take much longer, causing timeouts in the Windows service manager.
> The problem appears to be this:
> There is a pool of “MSC service threads”. These threads are responsible among other things for the publishing and also the unpublishing of web services, which involves the creation and also the deletion of WSDL files, using WSDLFilePublisher. These threads operate on deployment units, which means the JARs inside an EAR.
> The WSDL files are published in this structure:
> data/wsdl/Bar.ear/<Foo>.jar/, with one folder for each JAR that has WS.
> In jbossws-cxf-5.1.4, each of these threads would delete the files and the folder for one deployment unit, i.e. one JAR. The impact was that the root folder data/wsdl/Bar.ear/ would remain, which was reported as a JBWS-3992 and fixed in 5.1.5.
> The fixed, however, causes each thread to now traverse to the root deployment unit (Bar.ear) and recursively delete all files under data/wsdl/Bar.ear and the folder itself. The problem is that this causes multiple threads to attempt to delete the same tree of files in parallel, at least on Windows causing this to take ages.
> The change:
> [https://github.com/jbossws/jbossws-cxf/commit/162c9e4d44f9832de6b6147b3b9...]
> As a workaround, we've downgraded to 5.1.4, which made the issue go away.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months