[
https://issues.apache.org/jira/browse/CXF-6458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127909#comment-18127909
]
Colm O hEigeartaigh edited comment on CXF-6458 at 10/16/26 4:27 PM:
--------------------------------------------------------------------
Adding a possible patch for this.
*The problem:* if the {{cxf-services-ws-discovery-service}} jar is on the
classpath, WS-Discovery switches on automatically for every endpoint. It then
quietly creates a second, private CXF Bus to listen for UDP discovery messages.
Nothing ever shut that Bus down. When you stop the webapp in Tomcat, its worker
threads ({{{}default-workqueue-N{}}}) keep running. Those threads hold on to
the webapp’s classloader, so every start/stop leaks one classloader until
Tomcat is restarted.
*The fix:*
# *{{{}WSDiscoveryServerListener{}}}:* it now keeps track of which application
Buses are using the shared discovery service. When the last one shuts down, it
stops the UDP listener and shuts down the private Bus, so its threads end.
# *{{{}WSDiscoveryServiceImpl{}}}:*
** It has a new {{shutdown()}} method that does that cleanup.
** It sends its Hello/Bye messages through its own Bus. Before, it used
whichever application Bus happened to be current, and could keep a reference to
that Bus after it was gone.
** Side effect: Hello/Bye no longer pick up features or configuration from the
application’s Bus.
# *{{{}UDPDestination{}}}:* now that the UDP listener really does get stopped,
it no longer throws a NullPointerException or prints stack traces for a message
that arrives just as it closes.
# *{{{}OneWayProcessorInterceptor{}}}:* during shutdown it used to log a
misleading “Executor queue is full” WARNING. In that case it now logs at FINE
instead.
{*}Hello/Bye go through the discovery service’s own private Bus{*}, not the
application’s Bus. If someone has put features, interceptors or conduit
settings for discovery traffic on their application Bus, those no longer apply.
This matters most when the shared discovery service is used. The
{{WSDiscoveryServiceImpl(Bus)}} constructor now uses the Bus you pass in, which
is normally what was used before anyway. So this is for 4.3.0 only.
was (Author: coheigea):
Adding a possible patch for this.
*The problem:* if the {{cxf-services-ws-discovery-service}} jar is on the
classpath, WS-Discovery switches on automatically for every endpoint. It then
quietly creates a second, private CXF Bus to listen for UDP discovery messages.
Nothing ever shut that Bus down. When you stop the webapp in Tomcat, its worker
threads ({{{}default-workqueue-N{}}}) keep running. Those threads hold on to
the webapp’s classloader, so every start/stop leaks one classloader until
Tomcat is restarted.
*The fix:*
# *{{{}WSDiscoveryServerListener{}}}:* it now keeps track of which application
Buses are using the shared discovery service. When the last one shuts down, it
stops the UDP listener and shuts down the private Bus, so its threads end.
# *{{{}WSDiscoveryServiceImpl{}}}:*
** It has a new {{shutdown()}} method that does that cleanup.
** It sends its Hello/Bye messages through its own Bus. Before, it used
whichever application Bus happened to be current, and could keep a reference to
that Bus after it was gone.
** Side effect: Hello/Bye no longer pick up features or configuration from the
application’s Bus.
# *{{{}UDPDestination{}}}:* now that the UDP listener really does get stopped,
it no longer throws a NullPointerException or prints stack traces for a message
that arrives just as it closes.
# *{{{}OneWayProcessorInterceptor{}}}:* during shutdown it used to log a
misleading “Executor queue is full” WARNING. In that case it now logs at FINE
instead.
> CXF 3.1.0 memory leak (Tomcat)
> ------------------------------
>
> Key: CXF-6458
> URL: https://issues.apache.org/jira/browse/CXF-6458
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1
> Reporter: neil walker
> Assignee: Colm O hEigeartaigh
> Priority: Major
> Fix For: 4.3.0
>
> Attachments: ws-discovery-leak.patch
>
>
> I have created a CXF project using wsdl2java, make no changes (i.e. blank
> project) I deploy it to Tomcat 7 or 8. As soon as I click 'stop', without
> even calling it, I am getting SEVERE errors from Tomcat regarding memory
> leaks and inability to close threads. Every time I start/stop I get an
> additional WebappClassLoader (I have done a memory dump and checked using
> Eclipse MAT) for the webapp and it only gets fixed when I restart tomcat.
> Tomcat also reports this using the 'test for leaks' button.
> This originally happened on CXF2.7 so I upgraded to 3, I have also tried the
> very latest JAXB reference implementation.
> The stack trace is as follows:
> {code}
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(Automati
> cWorkQueueImpl.java:353)
> java.lang.Thread.run(Thread.java:722)
> 11-Jun-2015 15:45:33.142 SEVERE [http-nio-8080-exec-2]
> org.apache.catalina.loade
> r.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application
> [MyAcces
> sAPSServiceN] created a ThreadLocal with key of type
> [com.sun.xml.bind.v2.ClassF
> actory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@27765bfc]) and a value
> of t
> ype [java.util.WeakHashMap] (value [{class
> org.apache.cxf.ws.addressing.Attribut
> edURIType=java.lang.ref.WeakReference@4b9111a1}]) but failed to remove it
> when t
> he web application was stopped. Threads are going to be renewed over time to
> try
> and avoid a probable memory leak.
> 11-Jun-2015 15:45:33.143 SEVERE [http-nio-8080-exec-2]
> org.apache.catalina.loade
> r.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application
> [MyAcces
> sAPSServiceN] created a ThreadLocal with key of type
> [com.sun.xml.bind.v2.ClassF
> actory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@27765bfc]) and a value
> of t
> ype [java.util.WeakHashMap] (value [{class
> org.apache.cxf.ws.discovery.wsdl.Hell
> oType=java.lang.ref.WeakReference@211c87c9, class
> javax.xml.ws.wsaddressing.W3CE
> ndpointReference$Address=java.lang.ref.WeakReference@5816ae1a, class
> javax.xml.w
> s.wsaddressing.W3CEndpointReference=java.lang.ref.WeakReference@39005a24,
> class
> org.apache.cxf.ws.discovery.wsdl.ScopesType=java.lang.ref.WeakReference@461e0eb8
> , class java.util.ArrayList=java.lang.ref.WeakReference@5f5875fe, class
> javax.xm
> l.ws.wsaddressing.W3CEndpointReference$Elements=java.lang.ref.WeakReference@28aa
> a799}]) but failed to remove it when the web application was stopped. Threads
> ar
> e going to be renewed over time to try and avoid a probable memory leak.
> 11-Jun-2015 15:45:33.146 SEVERE [http-nio-8080-exec-2]
> org.apache.catalina.loade
> r.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application
> [MyAcces
> sAPSServiceN] created a ThreadLocal with key of type
> [com.sun.xml.bind.v2.ClassF
> actory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@27765bfc]) and a value
> of t
> ype [java.util.WeakHashMap] (value [{class
> org.apache.cxf.ws.addressing.Attribut
> edURIType=java.lang.ref.WeakReference@5be142aa}]) but failed to remove it
> when t
> he web application was stopped. Threads are going to be renewed over time to
> try
> and avoid a probable memory leak.
> 11-Jun-2015 15:45:33.148 SEVERE [http-nio-8080-exec-2]
> org.apache.catalina.loade
> r.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application
> [MyAcces
> sAPSServiceN] created a ThreadLocal with key of type
> [com.sun.xml.bind.v2.ClassF
> actory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@27765bfc]) and a value
> of t
> ype [java.util.WeakHashMap] (value [{class
> javax.xml.ws.wsaddressing.W3CEndpoint
> Reference$Address=java.lang.ref.WeakReference@21dfd606, class
> javax.xml.ws.wsadd
> ressing.W3CEndpointReference=java.lang.ref.WeakReference@6e5c3549, class
> org.apa
> che.cxf.ws.discovery.wsdl.ScopesType=java.lang.ref.WeakReference@67ae8439,
> class
> java.util.ArrayList=java.lang.ref.WeakReference@726aef5c, class
> org.apache.cxf.
> ws.discovery.wsdl.ByeType=java.lang.ref.WeakReference@4a88bbb3, class
> javax.xml.
> ws.wsaddressing.W3CEndpointReference$Elements=java.lang.ref.WeakReference@56db0a
> ff}]) but failed to remove it when the web application was stopped. Threads
> are
> going to be renewed over time to try and avoid a probable memory leak.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
