[potatosareok2]

I wonder why they approached the problem from the way they did -- that is to say the monitor the effect of the problem but not the cause (# open fd caused by stuck threads). Why not monitor the # JVM threads.

I'm somewhat familiar with a tool we use at work for monitoring JVM - wily introscope, but I'm sure there are other options available (newrelic java agent? ps can check nwlp on Linux? prstat available on linux? other jmx solutions?). Again I'm not familiar with tomcat as much as websphere/weblogic but I see tomcat has this option https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#S... which you can use in conjunction with other monitoring to get alerts I think for situations like this (your app threads getting stuck). I'm not sure if tomcat will write a warning log msg or actually mark the the thread as "STUCK" in thread dump.

The author did mention Java Mission Control but I wanted to point out that's not the only option for JVM monitoring.

[pigs]

There were only two threads stuck, so monitoring the threads wouldn't have set off any alarms. One was a Clojure agent thread, which basically allowed all the clients marked for retirement to queue up.

I used both Yourkit and Java Mission Control for monitoring the JVM. They both have some functionality of deadlock detection, but it did not flag these two threads. Yourkit identified these threads as waiting, not blocked, but I'm not sure how it makes that distinction.

[jamespo]

Jolokia is a nice solution which integrates well with Nagios & clones