As implementation - I assume you weren't going to add a native method and a .so library to the standalone tomcat distribution :-)
Adding capability to StatusServlet to report arbitrary mbean attributes
would make this feature easy to add ( there is some code in JmxProxyServlet - but it it would be much better if integrated and made consistent with the status servlet ).
For the JNI + mbean implementation - it may be better to use a separate component ( I don't see why it would be specific in any way to tomcat - any jmx-based app could use this ). There are several other OS-specific
informations of interest ( including in Windows ), JMX is designed exactly for this - to expose management info for different systems.
Costin
Peter Lin wrote:
that's why I decided it was a good idea to ask for other's thoughts. From a stress testing perspective, I find system load stats very valuable. breaking tomcat isn't something I find desirable either, but there has to be a better way to measure system load other than ssh into the server and use top.
manually doing top or sysinfo is fine for load testing, but for performance monitoring, something automated is desirable. My thought was to make it optional and have it detect whether or not a native lib for that platform exists. If it doesn't it would affect the status servlet and would look exactly the same as it does now.
on the otherhand, if the user enables it and a native lib exists, it could display the system load. the only other option is to lobby Sun to add system load stats to the VM, so that it is portable across platforms.
peter
On Fri, 31 Dec 2004 17:27:03 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
I would personally have some reservations about doing this... It's a little better if it's a module you can activate and deactivate, but still...
First, if it's not something you can do cross-platform, I'm not sure I'd like it. AFAIK Tomcat is nicely cross-platform now, anything that breaks that wouldn't be good I think. I understand this would be an optional component (right?), so it wouldn't actually be *breaking* anything, but the expectation I think is that anything in Tomcat works on all platforms, so would it be a good thing to introduce something that doesn't fit that mold?
Second, and more importantly, it doesn't feel right to me to expose this type of information through an app server. Your talking about statistics that aren't truly related to the app server, although is certainly affected by the app server, so it's debatable whether they should be there or not. I agree this is useful information to have access to, but I'm not sure it'd be the right place for it.
Have you considered maybe making this part of some Commons package? Make it something that any app could make use of, that might be a very nice thing. Heck, it might be somewhere in there already for all I know.
Just my thoughts on it anyway.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Peter Lin wrote:
it could be a separate module. It definitely should use MBean. In terms of getting the CPU load stats, I was thinking of calling the standard sysinfo loads[].
Is there some other way of getting the system load stats? or CPU stats? that doesn't require calling native code?
peter
On Fri, 31 Dec 2004 13:13:54 -0800, Costin Manolache <[EMAIL PROTECTED]> wrote:
Peter Lin wrote:
I'm thinking of adding system load stats to the status servlet. What do other's think about it? It would use JNI to call a native lib and it would only work on unix, but it would be good to have. I would also update JMeter in the process to display the system load average.
peter lin
Wouldn't be better to have a way to display an arbitrary mbean attribute, plus an mbean tracking system load ( and maybe memory/disk statistics ) ?
Dealing with jni is allways tricky ( including build issues, etc ) - it is better to have it in separate modules.
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
