[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 edited comment on JBWS-4088 at 4/18/19 10:34 PM:
--------------------------------------------------------
>From Alessio, we only need add some case for this jira.
was (Author: jim.ma):
>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.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[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 commented on JBWS-4088:
------------------------------
>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.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[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: (was: jbossws-cxf-5.3.0.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
>
> 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
[JBoss JIRA] (JBWS-4047) Enable / disable WS statistics does not reset counters
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4047?page=com.atlassian.jira.plugin.... ]
Jim Ma updated JBWS-4047:
-------------------------
Fix Version/s: (was: jbossws-cxf-5.3.0.Final)
> Enable / disable WS statistics does not reset counters
> ------------------------------------------------------
>
> Key: JBWS-4047
> URL: https://issues.jboss.org/browse/JBWS-4047
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-5.1.5.Final
> Reporter: Romain Pelisse
> Assignee: Alessio Soldano
> Priority: Major
>
> Enable / disable statistics does not reset counters.
> Right now when I enable stats - do some soap requests - disable stats - enable stats again - counters are not on 0 but continue when they were before disabling stats.
> I think reset of counters should be done once stats are disabled.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[JBoss JIRA] (JBWS-4154) jbossws-cxf-client depends on both jboss-jaxws-api_2.2_spec and jboss-jaxws-api_2.3_spec
by r searls (Jira)
[ https://issues.jboss.org/browse/JBWS-4154?page=com.atlassian.jira.plugin.... ]
r searls commented on JBWS-4154:
--------------------------------
Yes this is resolved.
> jbossws-cxf-client depends on both jboss-jaxws-api_2.2_spec and jboss-jaxws-api_2.3_spec
> ----------------------------------------------------------------------------------------
>
> Key: JBWS-4154
> URL: https://issues.jboss.org/browse/JBWS-4154
> Project: JBoss Web Services
> Issue Type: Bug
> Affects Versions: jbossws-cxf-5.2.4.Final
> Reporter: Jan Blizňák
> Assignee: r searls
> Priority: Major
> Fix For: jbossws-cxf-5.3.0.Final
>
>
> dependency:tree goal output shows that jbossws-cxf-client (and transitively other modules too) depends on two versions of JBoss JAX-WS API:
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:compile
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.3_spec:jar:1.0.0.Final:compile
> The former is brought in by:
> {code:java}
> +- org.jboss.ws.cxf:jbossws-cxf-transports-undertow:jar:5.2.5-SNAPSHOT:compile
> | \- org.jboss.ws.projects:jaxws-undertow-httpspi:jar:1.0.1.Final:compile
> | +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:compile
> {code}
> I guess we should stick to the newer one which would mean add some dependency exclude or update jaxws-undertow-httpspi to new API version stream (I vote for this)
> Whole dependency tree at https://github.com/jbliznak/jbws-dependency-trees/blob/jdk11-after/jbossw...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[JBoss JIRA] (JBWS-4138) JDK11 illegal reflective access warnings in gmavenplus-plugin
by r searls (Jira)
[ https://issues.jboss.org/browse/JBWS-4138?page=com.atlassian.jira.plugin.... ]
r searls commented on JBWS-4138:
--------------------------------
Yes this can be rejected
> JDK11 illegal reflective access warnings in gmavenplus-plugin
> -------------------------------------------------------------
>
> Key: JBWS-4138
> URL: https://issues.jboss.org/browse/JBWS-4138
> Project: JBoss Web Services
> Issue Type: Bug
> Affects Versions: jbossws-cxf-5.2.3.Final
> Reporter: Jan Blizňák
> Priority: Major
> Fix For: jbossws-cxf-5.3.0.Final
>
>
> When running build with JDK11, the execution of gmavenplus-plugin during testsuite prints illegal reflective access warnings
> {code:java}
> [INFO] --- gmavenplus-plugin:1.5:execute (testsuite-default) @ jbossws-cxf-specific-tests ---
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/home/jbliznak/.m2/repository/org/codehaus/groovy/groovy-all/2.4.15/groovy-all-2.4.15.jar) to method java.lang.Object.finalize()
> WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> This will become problem in JDK 12
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[JBoss JIRA] (JBWS-4154) jbossws-cxf-client depends on both jboss-jaxws-api_2.2_spec and jboss-jaxws-api_2.3_spec
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/JBWS-4154?page=com.atlassian.jira.plugin.... ]
Jim Ma commented on JBWS-4154:
------------------------------
[~rsearls] Can I update it to resolved now ?
> jbossws-cxf-client depends on both jboss-jaxws-api_2.2_spec and jboss-jaxws-api_2.3_spec
> ----------------------------------------------------------------------------------------
>
> Key: JBWS-4154
> URL: https://issues.jboss.org/browse/JBWS-4154
> Project: JBoss Web Services
> Issue Type: Bug
> Affects Versions: jbossws-cxf-5.2.4.Final
> Reporter: Jan Blizňák
> Assignee: r searls
> Priority: Major
> Fix For: jbossws-cxf-5.3.0.Final
>
>
> dependency:tree goal output shows that jbossws-cxf-client (and transitively other modules too) depends on two versions of JBoss JAX-WS API:
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:compile
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.3_spec:jar:1.0.0.Final:compile
> The former is brought in by:
> {code:java}
> +- org.jboss.ws.cxf:jbossws-cxf-transports-undertow:jar:5.2.5-SNAPSHOT:compile
> | \- org.jboss.ws.projects:jaxws-undertow-httpspi:jar:1.0.1.Final:compile
> | +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:compile
> {code}
> I guess we should stick to the newer one which would mean add some dependency exclude or update jaxws-undertow-httpspi to new API version stream (I vote for this)
> Whole dependency tree at https://github.com/jbliznak/jbws-dependency-trees/blob/jdk11-after/jbossw...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years