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.
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.