On 23/09/2010 13:52, Pid wrote: > Hi, > > > I've been playing with a CLI, JMX and a few other things. At work I am > manually extracting and monitoring various bits of JMX data in order to > diagnose problems with Tomcat configs and applications. > > There's lot of information available in the JVM & Tomcat which could be > polled periodically, (theoretically comparatively cheaply), in order to > determine if there is a problem developing or occurring. > > Some of this information could be collated and presented in a structured > format to enable more easy analysis. Tomcat could then self-diagnose > some common problems. > > > Rainer & I had a lengthy conversation at the Apache Retreat last weekend > and extrapolated, coming up with more ideas: > > - Periodic snaphots of key indicators, e.g. Connector backlog, error > counts, resource pool usage. > - A 'black box recorder' mode which can be enabled to log key data > - Periodic inspection of threads to warn about blocking, deadlocks > - A simple web UI (like the /manager) which presents & collates this > info and does some simple analysis > > It should also be possible to make some educated guesses about the > sources of common problems by doing statistical analysis of thread stacks. > > There are products on the market and app in the JDK which instrument > apps and perform profiling, but we concluded we can simulate some of > this with little performance cost. > > > There's a huge gap between understanding basic info, and understanding > what the JDK tools output. It should be possible for Tomcat provide an > intermediate level and help users improve their own analysis. > > No silver bullets, just a step up from the basics. > > > Thoughts? > > > p > > (@Rainer did I forget anything?)
I did forget something. A user asked if it was possible for Tomcat to detect duplicate classes in the classpath and report which jar they were in. p
0x62590808.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
