tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <>
Subject Re: Tomcat diagnostics
Date Sat, 25 Sep 2010 14:10:46 GMT
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.


View raw message