what about all the existing solutions that are there already? Doesn't it make more sense to embed in one of these instead of creating the n+1 ?
leon On Thu, Sep 23, 2010 at 8:17 PM, Pid <p...@pidster.com> wrote: > On 23/09/2010 17:30, Mark Thomas wrote: >> On 23/09/2010 05:52, Pid wrote: >>> - 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 >> >> Like it. I assume the same info would be available via JMX. For >> developers the web UI is the most important. For enterprises it is JMX >> (or maybe a simple text based outout) so the data can be integrated with >> other tools. > > Yep, JMX would be the primary location to get the data and enable the > BBR. The web UI would interact with JMX, as the Manager app does. > > > p > >>> It should also be possible to make some educated guesses about the >>> sources of common problems by doing statistical analysis of thread stacks. >> >> That sounds a little more tricky. >> >>> No silver bullets, just a step up from the basics. >>> >>> Thoughts? >> >> Overall, I like it. It fits in with the GSOC work to improve the JMX >> support (which is still a work in progress but improved a lot over the >> summer). >> >> Mark >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
