You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Manuel LeNormand <ma...@gmail.com> on 2013/05/25 22:41:45 UTC

Exeptions after upgrading to tomcat 7

Hello all,
I have a Solr instance running on a Tomcat 6 servlet, everything worked
fine.
While upgrading to Tomcat 7.0.34, I get exceptions I'm having a hard time
to deal with.
Two kind of exceptions occur on shutdown of service:
1. Memory leak due to threads that do not close - I understand it is not
severe, and maybe on previous version was not monitored. Still, is there
anything that is done on the servlet side that might resolve it, and what
might be sides effects of this?
2. Instance of MBeans that cannot be destroyed - btw,  the MBean instance
is initiated under CATALINA_OPTS.

Thanks in advance,
Manuel

Here are the LOGS:
INFO: A valid shutdown command was received via the shutdown port. Stopping
the Server instance.
May 13, 2013 4:22:32 PM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["http-bio-8080"]
May 13, 2013 4:22:32 PM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["ajp-bio-8009"]
May 13, 2013 4:22:32 PM org.apache.catalina.core.StandardService
stopInternal
INFO: Stopping service Catalina
May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/solr] appears to have started a thread named
[localhost-startStop-1-SendThread(zookeeper2:2181)] but has failed to stop
it. This is very likely to create a memory leak.
May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/solr] appears to have started a thread named
[localhost-startStop-1-EventThread] but has failed to stop it. This is very
likely to create a memory leak.
May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader
checkThreadLocalMapForLeaks
SEVERE: The web application [/solr] created a ThreadLocal with key of type
[org.apache.solr.schema.DateField.ThreadLocalDateFormat] (value
[org.apache.solr.schema.DateField$ThreadLocalDateFormat@19c212b0]) and a
value of type [org.apache.solr.schema.DateField.ISO8601CanonicalDateFormat]
(value [org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a])
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.
May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader
checkThreadLocalMapForLeaks
SEVERE: The web application [/solr] created a ThreadLocal with key of type
[org.apache.solr.schema.DateField.ThreadLocalDateFormat] (value
[org.apache.solr.schema.DateField$ThreadLocalDateFormat@19c212b0]) and a
value of type [org.apache.solr.schema.DateField.ISO8601CanonicalDateFormat]
(value [org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a])
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.
May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["http-bio-8080"]
May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["ajp-bio-8009"]
May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["http-bio-8080"]
May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["ajp-bio-8009"]
May 13, 2013 4:22:35 PM org.apache.catalina.util.LifecycleMBeanBase
unregister
WARNING: Failed to unregister MBean with name
[Catalina:type=Executor,name=tomcatThreadPool] during component destruction
javax.management.InstanceNotFoundException:
Catalina:type=Executor,name=tomcatThreadPool
        at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(Unknown
Source)
        at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(Unknown
Source)
        at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(Unknown
Source)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(Unknown
Source)
        at
org.apache.catalina.util.LifecycleMBeanBase.unregister(LifecycleMBeanBase.java:194)
        at
org.apache.catalina.util.LifecycleMBeanBase.destroyInternal(LifecycleMBeanBase.java:73)
        at
org.apache.catalina.core.StandardThreadExecutor.destroyInternal(StandardThreadExecutor.java:150)
        at
org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
        at
org.apache.catalina.core.StandardService.destroyInternal(StandardService.java:589)
        at
org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
        at
org.apache.catalina.core.StandardServer.destroyInternal(StandardServer.java:822)
        at
org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
        at org.apache.catalina.startup.Catalina.stop(Catalina.java:752)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:713)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451)

May 13, 2013 4:22:35 PM org.apache.catalina.deploy.NamingResources
destroyInternal
WARNING: Failed to destroy MBean for naming resource [UserDatabase]
javax.management.InstanceNotFoundException:
Users:type=UserDatabase,database=UserDatabase
        at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(Unknown
Source)
        at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(Unknown
Source)
        at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(Unknown
Source)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(Unknown
Source)
        at
org.apache.catalina.mbeans.MBeanUtils.destroyMBeanUserDatabase(MBeanUtils.java:1621)
        at
org.apache.catalina.mbeans.MBeanUtils.destroyMBean(MBeanUtils.java:1207)
        at
org.apache.catalina.deploy.NamingResources.destroyInternal(NamingResources.java:1084)
        at
org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
        at
org.apache.catalina.core.StandardServer.destroyInternal(StandardServer.java:825)
        at
org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
        at org.apache.catalina.startup.Catalina.stop(Catalina.java:752)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:713)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451)

Re: Exeptions after upgrading to tomcat 7

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Manuel,

On 5/25/13 4:41 PM, Manuel LeNormand wrote:
> Hello all, I have a Solr instance running on a Tomcat 6 servlet,
> everything worked fine. While upgrading to Tomcat 7.0.34, I get
> exceptions I'm having a hard time to deal with. Two kind of
> exceptions occur on shutdown of service: 1. Memory leak due to
> threads that do not close - I understand it is not severe, and
> maybe on previous version was not monitored. Still, is there 
> anything that is done on the servlet side that might resolve it,
> and what might be sides effects of this? 2. Instance of MBeans that
> cannot be destroyed - btw,  the MBean instance is initiated under
> CATALINA_OPTS.
> 
> Thanks in advance, Manuel
> 
> Here are the LOGS: INFO: A valid shutdown command was received via
> the shutdown port. Stopping the Server instance. May 13, 2013
> 4:22:32 PM org.apache.coyote.AbstractProtocol pause INFO: Pausing
> ProtocolHandler ["http-bio-8080"] May 13, 2013 4:22:32 PM
> org.apache.coyote.AbstractProtocol pause INFO: Pausing
> ProtocolHandler ["ajp-bio-8009"] May 13, 2013 4:22:32 PM
> org.apache.catalina.core.StandardService stopInternal INFO:
> Stopping service Catalina May 13, 2013 4:22:35 PM
> org.apache.catalina.loader.WebappClassLoader 
> clearReferencesThreads SEVERE: The web application [/solr] appears
> to have started a thread named 
> [localhost-startStop-1-SendThread(zookeeper2:2181)] but has failed
> to stop it. This is very likely to create a memory leak. May 13,
> 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader 
> clearReferencesThreads SEVERE: The web application [/solr] appears
> to have started a thread named [localhost-startStop-1-EventThread]
> but has failed to stop it. This is very likely to create a memory
> leak. May 13, 2013 4:22:35 PM
> org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks SEVERE: The web application [/solr]
> created a ThreadLocal with key of type 
> [org.apache.solr.schema.DateField.ThreadLocalDateFormat] (value 
> [org.apache.solr.schema.DateField$ThreadLocalDateFormat@19c212b0])
> and a value of type
> [org.apache.solr.schema.DateField.ISO8601CanonicalDateFormat] 
> (value
> [org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a])
>
> 
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. May 13, 2013 4:22:35 PM
> org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks SEVERE: The web application [/solr]
> created a ThreadLocal with key of type 
> [org.apache.solr.schema.DateField.ThreadLocalDateFormat] (value 
> [org.apache.solr.schema.DateField$ThreadLocalDateFormat@19c212b0])
> and a value of type
> [org.apache.solr.schema.DateField.ISO8601CanonicalDateFormat] 
> (value
> [org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a])
>
> 
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. May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol
> stop INFO: Stopping ProtocolHandler ["http-bio-8080"] May 13, 2013
> 4:22:35 PM org.apache.coyote.AbstractProtocol stop INFO: Stopping
> ProtocolHandler ["ajp-bio-8009"] May 13, 2013 4:22:35 PM
> org.apache.coyote.AbstractProtocol destroy INFO: Destroying
> ProtocolHandler ["http-bio-8080"] May 13, 2013 4:22:35 PM
> org.apache.coyote.AbstractProtocol destroy INFO: Destroying
> ProtocolHandler ["ajp-bio-8009"] May 13, 2013 4:22:35 PM
> org.apache.catalina.util.LifecycleMBeanBase unregister WARNING:
> Failed to unregister MBean with name 
> [Catalina:type=Executor,name=tomcatThreadPool] during component
> destruction javax.management.InstanceNotFoundException: 
> Catalina:type=Executor,name=tomcatThreadPool at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(Unknown
>
> 
Source)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(Unknown
>
> 
Source)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(Unknown
>
> 
Source)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(Unknown 
> Source) at 
> org.apache.catalina.util.LifecycleMBeanBase.unregister(LifecycleMBeanBase.java:194)
>
> 
at
> org.apache.catalina.util.LifecycleMBeanBase.destroyInternal(LifecycleMBeanBase.java:73)
>
> 
at
> org.apache.catalina.core.StandardThreadExecutor.destroyInternal(StandardThreadExecutor.java:150)
>
> 
at
> org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
>
> 
at
> org.apache.catalina.core.StandardService.destroyInternal(StandardService.java:589)
>
> 
at
> org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
>
> 
at
> org.apache.catalina.core.StandardServer.destroyInternal(StandardServer.java:822)
>
> 
at
> org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
>
> 
at org.apache.catalina.startup.Catalina.stop(Catalina.java:752)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:713) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at
> java.lang.reflect.Method.invoke(Unknown Source) at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322) at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451)
> 
> May 13, 2013 4:22:35 PM org.apache.catalina.deploy.NamingResources 
> destroyInternal WARNING: Failed to destroy MBean for naming
> resource [UserDatabase] 
> javax.management.InstanceNotFoundException: 
> Users:type=UserDatabase,database=UserDatabase at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(Unknown
>
> 
Source)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(Unknown
>
> 
Source)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(Unknown
>
> 
Source)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(Unknown 
> Source) at 
> org.apache.catalina.mbeans.MBeanUtils.destroyMBeanUserDatabase(MBeanUtils.java:1621)
>
> 
at
> org.apache.catalina.mbeans.MBeanUtils.destroyMBean(MBeanUtils.java:1207)
>
> 
at
> org.apache.catalina.deploy.NamingResources.destroyInternal(NamingResources.java:1084)
>
> 
at
> org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
>
> 
at
> org.apache.catalina.core.StandardServer.destroyInternal(StandardServer.java:825)
>
> 
at
> org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
>
> 
at org.apache.catalina.startup.Catalina.stop(Catalina.java:752)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:713) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at
> java.lang.reflect.Method.invoke(Unknown Source) at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322) at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451)
> 

Something looks very broken in your Tomcat installation: the startStop
thread(s) should not be created by a webapp. De-registering a Tomcat
MBean should not fail.

Can you re-install Tomcat (without your webapp) and verify that it
starts and stops without any problems? Then, re-add your webapp and
see what happens.

Which version of Solr are you running? A fairly stock Solr 4.2.1 does
not give any such warnings when I deploy it onto Tomcat 7.0.40.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRpNuDAAoJEBzwKT+lPKRYD8gP/0EfatV4frxZiUBW+kgD1q/U
/rABJRSQmRJr4GTzXOmx+s3cA7YUOgPmkSPG6+5VGPC8zXx98+nY4LW5wFh3bUIX
iWijF6xtItwZgZBU1oz4FbyOdLMwkGfnpn19DXYCkvVXiz+q/TUFWMiBbGa8nCYV
zqUdONm89fvivGBzshyc2Lgg79gGk7dHiE9KIQL0xP7nU+Xm9KIDqTsla+l9uFUf
Pltz0vY4w8GZJhoUrnLpG3zh2Skfc3shkLIdXw9qdIE19JjiHV6PzU8lBgC07PC+
PR+5+v9RWnm+XvgcNQXdJ0mYBAEHVSPWwRuOlE6s8ze8bYzeTmEJY3H6h1lyoXUe
sFQF+wdM0Eezt+uMSYdA4tEBvsVV/eCVU8vDWUo+dF59JAPTy6iQ2TZhnaFiextp
SS0/pTQAXLUdvgoJxepE5axR3yQ/XyHVz6vm2QTDZ52e9M9GOSuAQeN/lMjDIc+H
r6/gWSx1vSB8J1OwE3mrDfMEGff3lLHiI7N0XqPzLYy/y+2iIarktrUmQ6BMd12c
GTn4WIvkDSFAL7X0IYx5r6UMJNUT7pG5195YEMy7ZR9EEmFKXGkuk9mAGFFlAOdX
hB9oWEAtn833VJlXfE7ptBc3S+uhH3GK+c08qAkRtCxyiPvPtR15ZDAy3BoLCxJY
eet9M1NGijrPJFC2ObWc
=vRK2
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Exeptions after upgrading to tomcat 7

Posted by Manuel LeNormand <ma...@gmail.com>.
Hey again folks,
I understand well better after the informative discussion between you two
about this subject.

Do you have an idea about the mbean unregistration exception?

Cheers,
Manu
On May 26, 2013 5:06 PM, "Caldarale, Charles R" <Ch...@unisys.com>
wrote:

> > From: Leon Rosenberg [mailto:rosenberg.leon@gmail.com]
> > Subject: Re: Exeptions after upgrading to tomcat 7
>
> > First we are talking about a ThreadLocal, not Thread.
>
> Read the logs again; besides the ThreadLocal abuse, there are two threads
> left lying around:
>
> > > SEVERE: The web application [/solr] appears to have started a thread
> named
> > > [localhost-startStop-1-SendThread(zookeeper2:2181)] but has failed to
> stop
> > > it. This is very likely to create a memory leak.
> > > SEVERE: The web application [/solr] appears to have started a thread
> named
> > > [localhost-startStop-1-EventThread] but has failed to stop it. This is
> very
> > > likely to create a memory leak.
>
> > Maybe I'm missing something here, but I never seen how ThreadLocal does
> > real harm, neither I can imagine it, please enlighten me ;-)
>
> Abusing ThreadLocal (which is what's going on here) can have very serious
> side effects, depending on what's stored via the reference.  For example,
> if something specific to the request or session is kept in the ThreadLocal
> and not refreshed on the next unrelated request, inadvertent data sharing
> and potential corruption can occur.  During one of the Tomcat
> get-togethers, we had discussed associating ThreadLocal instances with
> sessions rather than Threads, but that would have been a good bit of work.
>  We settled on just purging such threads from the pool.
>
> Libraries written for non-thread-pool environments should be documented as
> such, and used only with great caution in server environments.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

RE: Exeptions after upgrading to tomcat 7

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leon Rosenberg [mailto:rosenberg.leon@gmail.com] 
> Subject: Re: Exeptions after upgrading to tomcat 7

> First we are talking about a ThreadLocal, not Thread.

Read the logs again; besides the ThreadLocal abuse, there are two threads left lying around:

> > SEVERE: The web application [/solr] appears to have started a thread named
> > [localhost-startStop-1-SendThread(zookeeper2:2181)] but has failed to stop
> > it. This is very likely to create a memory leak.
> > SEVERE: The web application [/solr] appears to have started a thread named
> > [localhost-startStop-1-EventThread] but has failed to stop it. This is very
> > likely to create a memory leak.

> Maybe I'm missing something here, but I never seen how ThreadLocal does
> real harm, neither I can imagine it, please enlighten me ;-)

Abusing ThreadLocal (which is what's going on here) can have very serious side effects, depending on what's stored via the reference.  For example, if something specific to the request or session is kept in the ThreadLocal and not refreshed on the next unrelated request, inadvertent data sharing and potential corruption can occur.  During one of the Tomcat get-togethers, we had discussed associating ThreadLocal instances with sessions rather than Threads, but that would have been a good bit of work.  We settled on just purging such threads from the pool.

Libraries written for non-thread-pool environments should be documented as such, and used only with great caution in server environments.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Exeptions after upgrading to tomcat 7

Posted by Leon Rosenberg <ro...@gmail.com>.
On Sun, May 26, 2013 at 3:14 PM, Caldarale, Charles R <
Chuck.Caldarale@unisys.com> wrote:

> > From: Leon Rosenberg [mailto:rosenberg.leon@gmail.com]
> > Subject: Re: Exeptions after upgrading to tomcat 7
>
> > Remove following lines from server.xml:
> >   <!-- Prevent memory leaks due to use of particular java/javax APIs-->
> >   <Listener
> > className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
> >   <Listener
> > className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>
> This is akin to burying one's head in the sand.  It would be much better
> to fix the actual problem by shutting down the auxiliary thread with an
> appropriate listener.  Sloppy programming should not be encouraged.
>

Chuck, with all respect, this is easier said than done.
First we are talking about a ThreadLocal, not Thread. It's tomcat who shuts
the threads done due to shutdown, not the app and not the library.
Now what is the negative impact of leaving a not-cleaned-up ThreadLocal?
- Memory footprint? Well, we are talking about few small objects, if the
app has millions of threads it probably has other problems.
- Garbage? Yes, but not more than any other Thread variable, it will be
collected by the GC once the Thread is collected.
- Reentrance? Any lib or code that uses ThreadLocals should initialize them
properly.

On the other hand efforts to clean it up.
You have to provide your own mechanism to clean up ThreadLocals someone
else created, because most libs aren't written for redeployment and simple
don't care. If they did, they would provide cleanup interfaces to their
libs, making them harder to use, but what for? Cleaning ThreadLocals up is
a bit like writing destructors.
Further, where is the safe place to actually clean up a ThreadLocal  The
same you created it? So if you want to ensure that you have your
threadlocal where you need it, you would set it up in filter, before
chain.doFilter() and clean it up in the finally block? Wait, what about
forwarded calls? They do not pass a filter, so your code would have to care
how it's been called. So RequestListener remains and it will surely have it
gotcha's too ;-)


All in one, a lot of hustle and bustle, and what for? To clean up 200 bytes
faster?
Maybe I'm missing something here, but I never seen how ThreadLocal does
real harm, neither I can imagine it, please enlighten me ;-)

regards
Leon



>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

RE: Exeptions after upgrading to tomcat 7

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leon Rosenberg [mailto:rosenberg.leon@gmail.com] 
> Subject: Re: Exeptions after upgrading to tomcat 7

> Remove following lines from server.xml:
>   <!-- Prevent memory leaks due to use of particular java/javax APIs-->
>   <Listener
> className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>   <Listener
> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

This is akin to burying one's head in the sand.  It would be much better to fix the actual problem by shutting down the auxiliary thread with an appropriate listener.  Sloppy programming should not be encouraged.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Exeptions after upgrading to tomcat 7

Posted by Leon Rosenberg <ro...@gmail.com>.
Hello Manuel,


On Sat, May 25, 2013 at 10:41 PM, Manuel LeNormand <
manuel.lenormand@gmail.com> wrote:

> Hello all,
> I have a Solr instance running on a Tomcat 6 servlet, everything worked
> fine.
> While upgrading to Tomcat 7.0.34, I get exceptions I'm having a hard time
> to deal with.
> Two kind of exceptions occur on shutdown of service:
> 1. Memory leak due to threads that do not close - I understand it is not
> severe, and maybe on previous version was not monitored. Still, is there
> anything that is done on the servlet side that might resolve it, and what
> might be sides effects of this?
>

Remove following lines from server.xml:
  <!-- Prevent memory leaks due to use of particular java/javax APIs-->
  <Listener
className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
  <Listener
className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

They do no good unless you are hotdeploying new versions of wars in running
production servers, and no one does that ;-)

regards
Leon



> 2. Instance of MBeans that cannot be destroyed - btw,  the MBean instance
> is initiated under CATALINA_OPTS.
>
> Thanks in advance,
> Manuel
>
> Here are the LOGS:
> INFO: A valid shutdown command was received via the shutdown port. Stopping
> the Server instance.
> May 13, 2013 4:22:32 PM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["http-bio-8080"]
> May 13, 2013 4:22:32 PM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["ajp-bio-8009"]
> May 13, 2013 4:22:32 PM org.apache.catalina.core.StandardService
> stopInternal
> INFO: Stopping service Catalina
> May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/solr] appears to have started a thread named
> [localhost-startStop-1-SendThread(zookeeper2:2181)] but has failed to stop
> it. This is very likely to create a memory leak.
> May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/solr] appears to have started a thread named
> [localhost-startStop-1-EventThread] but has failed to stop it. This is very
> likely to create a memory leak.
> May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/solr] created a ThreadLocal with key of type
> [org.apache.solr.schema.DateField.ThreadLocalDateFormat] (value
> [org.apache.solr.schema.DateField$ThreadLocalDateFormat@19c212b0]) and a
> value of type [org.apache.solr.schema.DateField.ISO8601CanonicalDateFormat]
> (value
> [org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a])
> 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.
> May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/solr] created a ThreadLocal with key of type
> [org.apache.solr.schema.DateField.ThreadLocalDateFormat] (value
> [org.apache.solr.schema.DateField$ThreadLocalDateFormat@19c212b0]) and a
> value of type [org.apache.solr.schema.DateField.ISO8601CanonicalDateFormat]
> (value
> [org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a])
> 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.
> May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["http-bio-8080"]
> May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["ajp-bio-8009"]
> May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["http-bio-8080"]
> May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["ajp-bio-8009"]
> May 13, 2013 4:22:35 PM org.apache.catalina.util.LifecycleMBeanBase
> unregister
> WARNING: Failed to unregister MBean with name
> [Catalina:type=Executor,name=tomcatThreadPool] during component destruction
> javax.management.InstanceNotFoundException:
> Catalina:type=Executor,name=tomcatThreadPool
>         at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(Unknown
> Source)
>         at
>
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(Unknown
> Source)
>         at
>
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(Unknown
> Source)
>         at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(Unknown
> Source)
>         at
>
> org.apache.catalina.util.LifecycleMBeanBase.unregister(LifecycleMBeanBase.java:194)
>         at
>
> org.apache.catalina.util.LifecycleMBeanBase.destroyInternal(LifecycleMBeanBase.java:73)
>         at
>
> org.apache.catalina.core.StandardThreadExecutor.destroyInternal(StandardThreadExecutor.java:150)
>         at
> org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
>         at
>
> org.apache.catalina.core.StandardService.destroyInternal(StandardService.java:589)
>         at
> org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
>         at
>
> org.apache.catalina.core.StandardServer.destroyInternal(StandardServer.java:822)
>         at
> org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
>         at org.apache.catalina.startup.Catalina.stop(Catalina.java:752)
>         at org.apache.catalina.startup.Catalina.start(Catalina.java:713)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>         at java.lang.reflect.Method.invoke(Unknown Source)
>         at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)
>         at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451)
>
> May 13, 2013 4:22:35 PM org.apache.catalina.deploy.NamingResources
> destroyInternal
> WARNING: Failed to destroy MBean for naming resource [UserDatabase]
> javax.management.InstanceNotFoundException:
> Users:type=UserDatabase,database=UserDatabase
>         at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(Unknown
> Source)
>         at
>
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(Unknown
> Source)
>         at
>
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(Unknown
> Source)
>         at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(Unknown
> Source)
>         at
>
> org.apache.catalina.mbeans.MBeanUtils.destroyMBeanUserDatabase(MBeanUtils.java:1621)
>         at
> org.apache.catalina.mbeans.MBeanUtils.destroyMBean(MBeanUtils.java:1207)
>         at
>
> org.apache.catalina.deploy.NamingResources.destroyInternal(NamingResources.java:1084)
>         at
> org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
>         at
>
> org.apache.catalina.core.StandardServer.destroyInternal(StandardServer.java:825)
>         at
> org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305)
>         at org.apache.catalina.startup.Catalina.stop(Catalina.java:752)
>         at org.apache.catalina.startup.Catalina.start(Catalina.java:713)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>         at java.lang.reflect.Method.invoke(Unknown Source)
>         at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)
>         at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451)
>