2014-06-05 19:19 GMT+04:00 Christopher Schultz <ch...@christopherschultz.net>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> All,
>
> One of dev instances this morning is screaming because I have hundreds
> of active sessions. I checked, and it looks like the background
> processor thread for the context is not running, therefore no sessions
> are expiring.
>
> Tomcat 7.0.52, Debian Linux x64, Oracle Java 1.7.0_55
>
> Here are the still-running threads:
>
> "catalina-exec-946"
> "Attach Listener"
> "MySQL Statement Cancellation Timer"
> "catalina-exec-338"
> "catalina-exec-337"
> "catalina-exec-5"
> "catalina-exec-4"
> "catalina-exec-3"
> "http-nio-127.0.0.1-8217-Acceptor-0"
> "http-nio-127.0.0.1-8217-ClientPoller-1"
> "http-nio-127.0.0.1-8217-ClientPoller-0"
> "ajp-bio-8215-AsyncTimeout"
> "ajp-bio-8215-Acceptor-0"
> "Memcached IO over {MemcachedConnection to localhost/127.0.0.1:11211}"
> "Abandoned connection cleanup thread"
> "Thread-3"
> "NioBlockingSelector.BlockPoller-1"
> "GC Daemon"
> "Service Thread"
> "C2 CompilerThread1"
> "C2 CompilerThread0"
> "Signal Dispatcher"
> "Finalizer"
> "Reference Handler"
> "main"
> "VM Thread"
> "GC task thread#0 (ParallelGC)"
> "GC task thread#1 (ParallelGC)"
> "VM Periodic Task Thread"
>
> I tried invoking "backgroundProcess" on my Manager bean via JMX but it
> didn't seem to actually clean anything up. Is there any hope of
> recovery without bouncing the web application?
>
> Also, it would be nice to get a notification if the thread is dying
> due to some exception. I searched-though catalina.out and found
> nothing relevant. Any suggestions?In general, dying threads are handled via Thread.setUncaughtExceptionHandler(...) and ThreadGroup.uncaughtException(...) The default behaviour in JRE it so log to System.err. So catalina.out is the place where I expect it to be written. (It is not nice as it bypasses logging framework, but that is how it is currently). A unusual culprit is OutOfMemoryError. > I tried invoking "backgroundProcess" on my Manager bean via JMX but it > didn't seem to actually clean anything up. Is there any hope of > recovery without bouncing the web application? The background thread is started via threadStart() which is called from ContainerBase.startInternal() / StandardContext.startInternal(). So I see no hope of recovering unless the container that owns the thread is stopped/started. I think that by default the thread is started by Engine, so Engine needs to be bounced here. BTW, javadoc for ContainerBase.backgroundProcess() says "This method will be invoked inside the classloading context of this container." I think that is not true when it is being invoked via JMX. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
