tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [5.0] Monitor servlet
Date Wed, 05 Mar 2003 18:18:50 GMT
Costin Manolache wrote:
> Remy Maucherat wrote:
>>I proposed that to Costin a few days ago, but got not so enthusiastic
>>The idea would be to add a new monitor servlet to the manager webapp. It
>>would generate data similar to It
>>would mostly (exclusively ?) use JMX to retrieve the components
> I'm not so enthusiastic for few reasons. We still have a lot of work 
> to do in our core area - and it seems the ammount of time most people
> have is limited. 

Well, I indeed have a few things on my task list, including:
- new static resource cache (the current one is inefficient both in 
terms of syncing and memory management)
- rewrite HTTP authentication using Coyote (this should be done in 
conjunction with the often talked about authorization refactoring, so 
that all realms support digest auth)
- optimization of the request dispatcher
- optimization of the Coyote HTTP/1.1 memory usage

> +1 on extending the manager servlet to also display monitoring data,
>  and to use the new JMX model - if 5.0 will use recommend using
> JMX to control tomcat, the manager should be an example of that instead
> of using the internal APIs.
> /manager is also close to /server-status ( or /jkstatus ). 

I agree. On the implementation side, I'll start with a separate servlet, 
outputting either simple HTML or better XML (with client side XSL; that 
would allow parsing by tools).

> There are 3 JMX consoles available ( each JMX impl. has one ). A generic 
> console would be nice - but it doesn't belong to tomcat ( maybe in commons).

As I said, I do not want to make a generic console, just a page which 
displays an overview of the TC status.

>>That's not a high priority task for me, but something I'd like to get
>>done eventually, and I'm looking for some feedback. I understand that
>>there are existing agents for JMX that can be used to provide more
>>powerful remote access to the statistics (HTTP, RMI, etc), but these
>>tools do not have the ability to give a user a quick and comprehensive
>>look at the Tomcat status (although they allow much more complex
>>operations, and it's not my objective to replace them).
> For remote statistics - I added a small experimental remote-JMX mechansim 
> for mod_jk ( which obviously can't support direct JMX ), and I plan to
> extend it and merge it in modeler. 
> IMO any generic JMX effort should be in commons ( modeler or a different
> component ). 

No, this is Tomcat specific stuff.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message