Re: [5.0] Monitor servlet
Remy, Could you move the manager servlets to webapps/manager ? As you can see, I can't touch build.xml without breaking something :-). I would also like to move the coyote/tomcat5 code in catalina - and eventually coyote/tomcat4 to jakarta-tomcat-4 and same for 3.3 ( preserving the same package names, I just want the code to be included in catalina.jar and in catalina sources ). The problem is that tomcat-coyote.jar is now dependent on all tomcats. Costin Jean-Francois Arcand wrote: Hi Remy, the servlet doesn't compile with JDK 1.3.x : StatusManagerServlet.java:274: cannot resolve symbol [javac] symbol : method maxMemory () [javac] location: class java.lang.Runtime [javac] writer.print(Runtime.getRuntime().maxMemory()); [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 1 error This method is only available with JDK 1.4 +. -- Jeanfrancois Remy Maucherat wrote: Remy Maucherat wrote: Hi, I proposed that to Costin a few days ago, but got not so enthusiastic comments. The idea would be to add a new monitor servlet to the manager webapp. It would generate data similar to http://www.apache.org/server-status. It would mostly (exclusively ?) use JMX to retrieve the components statistics. 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). I've committed a rough version of the monitoring servlet. It will display status information for all Coyote connectors, using JMX exclusively. I don't think there's any statistic missing (the amount of meaningful status information available to a Java program is definitely much lower than for a native Unix program, hence the simpler look when compared to the Apache status). The thing is very rough, and could use contributions (hint, hint) :) As for using it, the monitor servlet is linked from the default Tomcat welcome page. It currently requires the same credentials as the rest of the manager webapp to access. Remy - 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]
Re: [5.0] Monitor servlet
Costin Manolache wrote: Remy, Could you move the manager servlets to webapps/manager ? As you can see, I can't touch build.xml without breaking something :-). I would also like to move the coyote/tomcat5 code in catalina - and eventually coyote/tomcat4 to jakarta-tomcat-4 and same for 3.3 ( preserving the same package names, I just want the code to be included in catalina.jar and in catalina sources ). The problem is that tomcat-coyote.jar is now dependent on all tomcats. Yes. All of these are logical steps, which have to be done gradually. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: Costin Manolache wrote: Remy, Could you move the manager servlets to webapps/manager ? As you can see, I can't touch build.xml without breaking something :-). I would also like to move the coyote/tomcat5 code in catalina - and eventually coyote/tomcat4 to jakarta-tomcat-4 and same for 3.3 ( preserving the same package names, I just want the code to be included in catalina.jar and in catalina sources ). The problem is that tomcat-coyote.jar is now dependent on all tomcats. Yes. All of these are logical steps, which have to be done gradually. BTW, there's weird stuff going on, that I noticed with the new status servlet. The problem is that, when I refresh, the requestCount goes up by two (?). I think it should be only one. Also, the max request time has a tendency to become equal to the connection timeout (which indicates the stats get updated in a situation where it shouldn't). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: I've committed a rough version of the monitoring servlet. It will display status information for all Coyote connectors, using JMX exclusively. I don't think there's any statistic missing (the amount of meaningful status information available to a Java program is definitely much lower than for a native Unix program, hence the simpler look when compared to the Apache status). The thing is very rough, and could use contributions (hint, hint) :) As for using it, the monitor servlet is linked from the default Tomcat welcome page. It currently requires the same credentials as the rest of the manager webapp to access. Few comments - in Konqueror, it just doesn't work. In Galeon - it's completely ugly. In Mozilla 1.3 - same as in galeon. I could go to a windows box and try it in IE - but it's easier to say -1 unless it can be used in other browsers :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: Remy Maucherat wrote: Costin Manolache wrote: Remy, Could you move the manager servlets to webapps/manager ? As you can see, I can't touch build.xml without breaking something :-). I would also like to move the coyote/tomcat5 code in catalina - and eventually coyote/tomcat4 to jakarta-tomcat-4 and same for 3.3 ( preserving the same package names, I just want the code to be included in catalina.jar and in catalina sources ). The problem is that tomcat-coyote.jar is now dependent on all tomcats. Yes. All of these are logical steps, which have to be done gradually. BTW, there's weird stuff going on, that I noticed with the new status servlet. The problem is that, when I refresh, the requestCount goes up by two (?). I think it should be only one. Also, the max request time has a tendency to become equal to the connection timeout (which indicates the stats get updated in a situation where it shouldn't). For the first part: aren't you using a stylesheet ? That will be downloaded as well when you refresh ? For the second: that's weird. I haven't seen it. Note that maxTime is R/W - a monitoring app can periodically reset it ( for example if you want maxTime for intervals ). ( BTW - sorry for the previous post with -1, but I really hate web pages that work only on MSIE ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Tim Funk wrote: I am in the process of reworking the style sheet to make it prettier. (I do my testing in mozilla) I will also try to: - create a DTD which will explain the xml output - add an option to allow the user to change the style sheet - incorporate more information into the XML doc output - wish to change the user who can see this ( So a help desk or monitoring app can use this without having all the privledges of manager) Please, don't ! Just display plain XHTML - it is a very bad idea to display the page in XML+XSL. Also I am very strongly against creating arbitrary XML DTDs ( and the current DTD is one very bad form - it's not extensible, etc ). I hope to have a submit a pathc tomorrow. With luck I will also post a demonstration page to so anyone can see the results without having to compile/run the code too. I'm strongly -1 ( ==veto ) on this implementation ( even if you manage to make it work in Mozilla ). XML+XSL is not supported in many browsers, it is overkill. The used DTD is pretty bad too. ( it seems even MSIE5.5 has problems displaying the page ! Do I have to install WindowsXP to see the tomcat page ? ) Costin -Tim Costin Manolache wrote: Remy Maucherat wrote: I've committed a rough version of the monitoring servlet. It will display status information for all Coyote connectors, using JMX exclusively. I don't think there's any statistic missing (the amount of meaningful status information available to a Java program is definitely much lower than for a native Unix program, hence the simpler look when compared to the Apache status). The thing is very rough, and could use contributions (hint, hint) :) As for using it, the monitor servlet is linked from the default Tomcat welcome page. It currently requires the same credentials as the rest of the manager webapp to access. Few comments - in Konqueror, it just doesn't work. In Galeon - it's completely ugly. In Mozilla 1.3 - same as in galeon. I could go to a windows box and try it in IE - but it's easier to say -1 unless it can be used in other browsers :-) 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]
Re: [5.0] Monitor servlet
Do you mean take the XML doc and perform an xslt transformation on the server before it gets sent to the client? (I thought original patch did that.) The dtd was really just an easy explanation of what the fields meant. The only reason I suggested this was if an xml doc is published (which it seems your leaning against), then a user will ask what the fields mean. My reason for leaning towards an xml doc is so I can push fields to MRTG (or similar) in the future. Or so I can easily integrate this into my helpdesk. I submit some changes and get rejected, I won't take it personally. I'll just keep trying. -Tim Costin Manolache wrote: Tim Funk wrote: I am in the process of reworking the style sheet to make it prettier. (I do my testing in mozilla) I will also try to: - create a DTD which will explain the xml output - add an option to allow the user to change the style sheet - incorporate more information into the XML doc output - wish to change the user who can see this ( So a help desk or monitoring app can use this without having all the privledges of manager) Please, don't ! Just display plain XHTML - it is a very bad idea to display the page in XML+XSL. Also I am very strongly against creating arbitrary XML DTDs ( and the current DTD is one very bad form - it's not extensible, etc ). I hope to have a submit a pathc tomorrow. With luck I will also post a demonstration page to so anyone can see the results without having to compile/run the code too. I'm strongly -1 ( ==veto ) on this implementation ( even if you manage to make it work in Mozilla ). XML+XSL is not supported in many browsers, it is overkill. The used DTD is pretty bad too. ( it seems even MSIE5.5 has problems displaying the page ! Do I have to install WindowsXP to see the tomcat page ? ) Costin -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Tim Funk wrote: Do you mean take the XML doc and perform an xslt transformation on the server before it gets sent to the client? (I thought original patch did that.) No, just return HTML in the first place. I just don't understand - when you can just display HTML, why do you want to go through XML and then XSLT ??? The dtd was really just an easy explanation of what the fields meant. The only reason I suggested this was if an xml doc is published (which it seems your leaning against), then a user will ask what the fields mean. My reason for leaning towards an xml doc is so I can push fields to MRTG (or similar) in the future. Or so I can easily integrate this into my helpdesk. I submit some changes and get rejected, I won't take it personally. I'll just keep trying. XHTML is also XML. Do the XSLT transformation to whatever XML format you want - instead of forcing the vast majority of people who'll just use the browser to go through a XSLT transformation. I'm ok with a separate servlet that generates an XML. But if we do that - we should use a format that is extensible or check what other people are doing instead of just inventing one. Apache doesn't seem to generate an XML or other complexities - and there are apps that can parse it and do whatever they need to do. Costin -Tim Costin Manolache wrote: Tim Funk wrote: I am in the process of reworking the style sheet to make it prettier. (I do my testing in mozilla) I will also try to: - create a DTD which will explain the xml output - add an option to allow the user to change the style sheet - incorporate more information into the XML doc output - wish to change the user who can see this ( So a help desk or monitoring app can use this without having all the privledges of manager) Please, don't ! Just display plain XHTML - it is a very bad idea to display the page in XML+XSL. Also I am very strongly against creating arbitrary XML DTDs ( and the current DTD is one very bad form - it's not extensible, etc ). I hope to have a submit a pathc tomorrow. With luck I will also post a demonstration page to so anyone can see the results without having to compile/run the code too. I'm strongly -1 ( ==veto ) on this implementation ( even if you manage to make it work in Mozilla ). XML+XSL is not supported in many browsers, it is overkill. The used DTD is pretty bad too. ( it seems even MSIE5.5 has problems displaying the page ! Do I have to install WindowsXP to see the tomcat page ? ) Costin -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Costin Manolache wrote: Tim Funk wrote: Do you mean take the XML doc and perform an xslt transformation on the server before it gets sent to the client? (I thought original patch did that.) No, just return HTML in the first place. Feel free to revert to the previous version. -1 from me for server side XSL (we're doing a monitor servlet, not a bring-ther-server-to-its-knees monitor servlet). I just don't understand - when you can just display HTML, why do you want to go through XML and then XSLT ??? Don't ask me. You didn't reply, and I didn't care, so I applied the patch (partially) ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: No, just return HTML in the first place. Feel free to revert to the previous version. -1 from me for server side XSL (we're doing a monitor servlet, not a bring-ther-server-to-its-knees monitor servlet). I just don't understand - when you can just display HTML, why do you want to go through XML and then XSLT ??? Don't ask me. You didn't reply, and I didn't care, so I applied the patch (partially) ;-) I couldn't reply - it didn't work for me :-) I just got it to work today. I was working with the embed version, with no servlet-XXX.jar. BTW - is there anything specific to tomcat5 in this app ? From what I see, it should work with 1.4 just fine ( well, except that it won't load if o.a.catalina package is used without backporting the fix from ServletWrapper ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Costin Manolache wrote: Remy Maucherat wrote: No, just return HTML in the first place. Feel free to revert to the previous version. -1 from me for server side XSL (we're doing a monitor servlet, not a bring-ther-server-to-its-knees monitor servlet). I just don't understand - when you can just display HTML, why do you want to go through XML and then XSLT ??? Don't ask me. You didn't reply, and I didn't care, so I applied the patch (partially) ;-) I couldn't reply - it didn't work for me :-) I just got it to work today. I was working with the embed version, with no servlet-XXX.jar. BTW - is there anything specific to tomcat5 in this app ? From what I see, it should work with 1.4 just fine ( well, except that it won't load if o.a.catalina package is used without backporting the fix from ServletWrapper ) Let's say the servlet doesn't have any obvious couplings with 5.0. However, it needs the updated modeler (without introspection, it won't work), as well as the JMX enabled Coyote. I don't want to port back that right now. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: No, just return HTML in the first place. Feel free to revert to the previous version. -1 from me for server side XSL (we're doing a monitor servlet, not a bring-ther-server-to-its-knees monitor servlet). I just don't understand - when you can just display HTML, why do you want to go through XML and then XSLT ??? Don't ask me. You didn't reply, and I didn't care, so I applied the patch (partially) ;-) I couldn't reply - it didn't work for me :-) I just got it to work today. I was working with the embed version, with no servlet-XXX.jar. BTW - is there anything specific to tomcat5 in this app ? From what I see, it should work with 1.4 just fine ( well, except that it won't load if o.a.catalina package is used without backporting the fix from ServletWrapper ) Let's say the servlet doesn't have any obvious couplings with 5.0. However, it needs the updated modeler (without introspection, it won't work), as well as the JMX enabled Coyote. I don't want to port back that right now. No need to back port it. I was just thinking that the manager and most of the other webapps are now relatively independent of the tomcat internals - and with JMX they can have almost no direct dependency ( except the naming scheme and semantics, of course ). Even webdav - it shouldn't be hard to either replace it with slide or make it depend only on JNDI ( and get the JNDI context via JMX ). Don't worry - I'm not going to touch any of those until the core is stable. The low coupling and relatively independent components are very good. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Costin Manolache wrote: For the first part: aren't you using a stylesheet ? That will be downloaded as well when you refresh ? I think that's the right explanation. For the second: that's weird. I haven't seen it. Note that maxTime is R/W - a monitoring app can periodically reset it ( for example if you want maxTime for intervals ). ( BTW - sorry for the previous post with -1, but I really hate web pages that work only on MSIE ) They worked good with my Moz 1.3 (which I use in my main browser), and with IE, of course. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
I am in the process of reworking the style sheet to make it prettier. (I do my testing in mozilla) I will also try to: - create a DTD which will explain the xml output - add an option to allow the user to change the style sheet - incorporate more information into the XML doc output - wish to change the user who can see this ( So a help desk or monitoring app can use this without having all the privledges of manager) I hope to have a submit a pathc tomorrow. With luck I will also post a demonstration page to so anyone can see the results without having to compile/run the code too. -Tim Costin Manolache wrote: Remy Maucherat wrote: I've committed a rough version of the monitoring servlet. It will display status information for all Coyote connectors, using JMX exclusively. I don't think there's any statistic missing (the amount of meaningful status information available to a Java program is definitely much lower than for a native Unix program, hence the simpler look when compared to the Apache status). The thing is very rough, and could use contributions (hint, hint) :) As for using it, the monitor servlet is linked from the default Tomcat welcome page. It currently requires the same credentials as the rest of the manager webapp to access. Few comments - in Konqueror, it just doesn't work. In Galeon - it's completely ugly. In Mozilla 1.3 - same as in galeon. I could go to a windows box and try it in IE - but it's easier to say -1 unless it can be used in other browsers :-) 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]
Re: [5.0] Monitor servlet
Tim Funk wrote: Looks good. Can I propose an (close) alternative? Can the status servlet produce an XML document? Then the XML document can either parsed by some third party app or it can be transformed in place to anyone's liking via XSLT. It has been decided earlier that it would produce XHTML. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Jean-Francois Arcand wrote: Hi Remy, the servlet doesn't compile with JDK 1.3.x : StatusManagerServlet.java:274: cannot resolve symbol [javac] symbol : method maxMemory () [javac] location: class java.lang.Runtime [javac] writer.print(Runtime.getRuntime().maxMemory()); [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 1 error This method is only available with JDK 1.4 +. Any ideas of alternatives ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: Jean-Francois Arcand wrote: Hi Remy, the servlet doesn't compile with JDK 1.3.x : StatusManagerServlet.java:274: cannot resolve symbol [javac] symbol : method maxMemory () [javac] location: class java.lang.Runtime [javac] writer.print(Runtime.getRuntime().maxMemory()); [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 1 error This method is only available with JDK 1.4 +. Any ideas of alternatives ? I've just look at the jdk souce code and this method is native :-(, so I don't see an easy way to port itMaybe you can use reflection and return |Long.MAX_VALUE| http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Long.html#MAX_VALUE if jdk 1.4? -- Jeanfrancois Remy - 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]
Re: [5.0] Monitor servlet
- Original Message - From: Jean-Francois Arcand [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, March 24, 2003 8:21 AM Subject: Re: [5.0] Monitor servlet Remy Maucherat wrote: Jean-Francois Arcand wrote: Hi Remy, the servlet doesn't compile with JDK 1.3.x : StatusManagerServlet.java:274: cannot resolve symbol [javac] symbol : method maxMemory () [javac] location: class java.lang.Runtime [javac] writer.print(Runtime.getRuntime().maxMemory()); [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 1 error This method is only available with JDK 1.4 +. Any ideas of alternatives ? I've just look at the jdk souce code and this method is native :-(, so I don't see an easy way to port itMaybe you can use reflection and return |Long.MAX_VALUE| http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Long.html#MAX_VALUE if jdk 1.4? It would be much easier to just add a getRuntimeMaxMemory method to o.a.t.u.compat.JdkCompat. That's what it's there for. -- Jeanfrancois Remy - 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]
[PATCH] add JdkCompat.maxMemory() [was Re: [5.0] Monitor servlet]
Here's a patch to JdkCompat, and JdkCompat1.4
The method is called getMaxMemory() and returns -1 for jdk1.3 or less.
Why -1? I had to pick a number. Feel free to change.
I do not have a patch yet for StatusManagerServlet. With luck, I'll have
a patch for that(with additional functionality) in the near future.
-Tim
Bill Barker wrote:
Any ideas of alternatives ?
I've just look at the jdk souce code and this method is native :-(, so I
don't see an easy way to port itMaybe you can use reflection and
return |Long.MAX_VALUE|
http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Long.html#MAX_VALUE
if jdk 1.4?
It would be much easier to just add a getRuntimeMaxMemory method to
o.a.t.u.compat.JdkCompat. That's what it's there for.
Index: JdkCompat.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/JdkCompat.java,v
retrieving revision 1.3
diff -u -r1.3 JdkCompat.java
--- JdkCompat.java 5 Feb 2003 03:47:12 - 1.3
+++ JdkCompat.java 24 Mar 2003 20:57:57 -
@@ -192,5 +192,16 @@
return realFile.toURL();
}
+
+/**
+ * Wrapper around Runtime.getRuntime().maxMemory().
+ * But this method does not exist it 1.3 or less so
+ * just return -1.
+ *
+ * @return -1
+ */
+public long getMaxMemory() {
+return -1;
+}
}
Index: Jdk14Compat.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/Jdk14Compat.java,v
retrieving revision 1.2
diff -u -r1.2 Jdk14Compat.java
--- Jdk14Compat.java4 Feb 2003 07:16:47 - 1.2
+++ Jdk14Compat.java24 Mar 2003 20:57:58 -
@@ -114,4 +114,14 @@
}
+/**
+ * Wrapper around Runtime.getRuntime().maxMemory()
+ *
+ * @return see Runtime.getRuntime().maxMemory()
+ */
+public long getMaxMemory() {
+return Runtime.getRuntime().maxMemory();
+}
+
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: Hi, I proposed that to Costin a few days ago, but got not so enthusiastic comments. The idea would be to add a new monitor servlet to the manager webapp. It would generate data similar to http://www.apache.org/server-status. It would mostly (exclusively ?) use JMX to retrieve the components statistics. 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). I've committed a rough version of the monitoring servlet. It will display status information for all Coyote connectors, using JMX exclusively. I don't think there's any statistic missing (the amount of meaningful status information available to a Java program is definitely much lower than for a native Unix program, hence the simpler look when compared to the Apache status). The thing is very rough, and could use contributions (hint, hint) :) As for using it, the monitor servlet is linked from the default Tomcat welcome page. It currently requires the same credentials as the rest of the manager webapp to access. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Hi Remy, the servlet doesn't compile with JDK 1.3.x : StatusManagerServlet.java:274: cannot resolve symbol [javac] symbol : method maxMemory () [javac] location: class java.lang.Runtime [javac] writer.print(Runtime.getRuntime().maxMemory()); [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 1 error This method is only available with JDK 1.4 +. -- Jeanfrancois Remy Maucherat wrote: Remy Maucherat wrote: Hi, I proposed that to Costin a few days ago, but got not so enthusiastic comments. The idea would be to add a new monitor servlet to the manager webapp. It would generate data similar to http://www.apache.org/server-status. It would mostly (exclusively ?) use JMX to retrieve the components statistics. 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). I've committed a rough version of the monitoring servlet. It will display status information for all Coyote connectors, using JMX exclusively. I don't think there's any statistic missing (the amount of meaningful status information available to a Java program is definitely much lower than for a native Unix program, hence the simpler look when compared to the Apache status). The thing is very rough, and could use contributions (hint, hint) :) As for using it, the monitor servlet is linked from the default Tomcat welcome page. It currently requires the same credentials as the rest of the manager webapp to access. Remy - 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]
Re: [5.0] Monitor servlet
Looks good. Can I propose an (close) alternative?
Can the status servlet produce an XML document? Then the XML document
can either parsed by some third party app or it can be transformed in
place to anyone's liking via XSLT.
Attached are examples of a (very) quick example of what I mean. There
should be 2 attachments, StatusManagerServlet2 and xform.xsl. The
servlet can take an additional parameter xsltFileName which will
transform the output. If not specified, then the raw xml will be
produced. So to change the look and feel - all you need to do is change
the init parameter.
If anyone wishes to suggest what the xml dtd should look like, I have no
attachments to the code above. It was a quick proof of concept.
For those writing monitoring applications and wish not to use JMX to
pull their measurements, an XML doc could be a convenient alternative.
-Tim
Remy Maucherat wrote:
Remy Maucherat wrote:
Hi,
I proposed that to Costin a few days ago, but got not so enthusiastic
comments.
The idea would be to add a new monitor servlet to the manager webapp.
It would generate data similar to http://www.apache.org/server-status.
It would mostly (exclusively ?) use JMX to retrieve the components
statistics.
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).
I've committed a rough version of the monitoring servlet. It will
display status information for all Coyote connectors, using JMX
exclusively. I don't think there's any statistic missing (the amount of
meaningful status information available to a Java program is definitely
much lower than for a native Unix program, hence the simpler look when
compared to the Apache status).
The thing is very rough, and could use contributions (hint, hint) :)
As for using it, the monitor servlet is linked from the default Tomcat
welcome page. It currently requires the same credentials as the rest of
the manager webapp to access.
Remy
?xml version=1.0?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
!-- Output method --
xsl:output method=xhtml
encoding=iso-8859-1
indent=no/
xsl:template match=status
html
head
TITLETomcat Status/TITLE
STYLE type=text/css
body, table, tr, td, a, div, span {
vertical-align : top;
}
/STYLE
/head
body
div style='font-size:20px;'Tomcat Status/div
xsl:apply-templates select=jvm/
xsl:apply-templates select=connector/
/body
/html
/xsl:template
xsl:template match=jvm
xsl:apply-templates select=memory/
/xsl:template
xsl:template match=memory
tabletr
tdbJVM:/b/td
tdbfree:/b xsl:value-of select=@free//td
tdbtotal:/b xsl:value-of select=@total//td
tdbmax:/b xsl:value-of select=@max//td
/tr
/tablehr /
/xsl:template
xsl:template match=connector
bConnector -- /b xsl:value-of select=@name/br /
xsl:apply-templates select=threadInfo/
xsl:apply-templates select=requestInfo/
xsl:apply-templates select=workers/
/xsl:template
xsl:template match=threadInfo
tabletr
tdbthreadInfo /b/td
tdbmaxThreads:/b xsl:value-of select=@maxThreads//td
tdbminSpareThreads:/b xsl:value-of select=@minSpareThreads//td
tdbmaxSpareThreads:/b xsl:value-of select=@maxSpareThreads//td
tdbcurrentThreadCount:/b xsl:value-of select=@currentThreadCount//td
tdbcurrentThreadsBusy:/b xsl:value-of select=@currentThreadsBusy//td
/tr
/tablehr /
/xsl:template
xsl:template match=requestInfo
tabletr
tdbrequestInfo /b/td
tdbmaxTime:/b xsl:value-of select=@maxTime//td
tdbprocessingTime:/b xsl:value-of select=@processingTime//td
tdbrequestCount:/b xsl:value-of select=@requestCount//td
tdberrorCount:/b xsl:value-of select=@errorCount//td
tdbbytesReceived:/b xsl:value-of select=@bytesReceived//td
tdbbytesSent:/b xsl:value-of select=@bytesSent//td
/tr
/tablehr /
/xsl:template
xsl:template match=workers
table
trthStage/ththTime/ththB Sent/ththB Recv/ththClient/ththVHost/ththRequest/th/tr
xsl:apply-templates select=worker/
/table
/xsl:template
xsl:template match=worker
tr
tdxsl:apply-templates select=stage//td
tdxsl:apply-templates select=requestProcessingTime//td
tdxsl:apply-templates select=requestBytesSent//td
tdxsl:apply-templates select=requestBytesReceived//td
tdxsl:apply-templates select=remoteAddr//td
tdxsl:apply-templates select=remoteAddr//td
tdxsl:apply-templates
RE: [5.0] Monitor servlet
Howdy, I'd be interested and willing to help implement this. Yoav Shapira Millennium ChemInformatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 9:19 AM To: Tomcat Developers List Subject: [5.0] Monitor servlet Hi, I proposed that to Costin a few days ago, but got not so enthusiastic comments. The idea would be to add a new monitor servlet to the manager webapp. It would generate data similar to http://www.apache.org/server-status. It would mostly (exclusively ?) use JMX to retrieve the components statistics. 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). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: Hi, I proposed that to Costin a few days ago, but got not so enthusiastic comments. The idea would be to add a new monitor servlet to the manager webapp. It would generate data similar to http://www.apache.org/server-status. It would mostly (exclusively ?) use JMX to retrieve the components statistics. 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). Good idea +0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
+1 (Nonbinding, and I have not programmed anything using JMX yet) -Tim Remy Maucherat wrote: Hi, I proposed that to Costin a few days ago, but got not so enthusiastic comments. The idea would be to add a new monitor servlet to the manager webapp. It would generate data similar to http://www.apache.org/server-status. It would mostly (exclusively ?) use JMX to retrieve the components statistics. 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). Remy - 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]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: Hi, I proposed that to Costin a few days ago, but got not so enthusiastic comments. The idea would be to add a new monitor servlet to the manager webapp. It would generate data similar to http://www.apache.org/server-status. It would mostly (exclusively ?) use JMX to retrieve the components statistics. 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. +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 ). 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). 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 ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
+0 (I have little time to help those day) -- Jeanfrancois Remy Maucherat wrote: Hi, I proposed that to Costin a few days ago, but got not so enthusiastic comments. The idea would be to add a new monitor servlet to the manager webapp. It would generate data similar to http://www.apache.org/server-status. It would mostly (exclusively ?) use JMX to retrieve the components statistics. 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). Remy - 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]
Re: [5.0] Monitor servlet
Costin Manolache wrote: Remy Maucherat wrote: Hi, I proposed that to Costin a few days ago, but got not so enthusiastic comments. The idea would be to add a new monitor servlet to the manager webapp. It would generate data similar to http://www.apache.org/server-status. It would mostly (exclusively ?) use JMX to retrieve the components statistics. 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. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: 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) Any chance you'll make this a bit more independent of the internals - I tried to do a bit of refactoring, but you know the code best. And maybe put it in commons. I don't know if you track it - but there is a lot of interest in JNDI and the stuff that is in tomcat. - 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) Yes, and maybe change the default realm to JAAS... If anyone has the time to do the implementation. +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). Ok - but at least keep it part of the /manager webapp. Simple XHTML is the best ( and fastest ), and if you want client-side processing, you can do it on top of XHTML ( just include some id or class attributes when you generate the XHTML - and XSLT can process it). It's a very nice technique to keep things both REST and be able to do XSLT or other programatic changes. 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. +1. 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. Yes - if you want to have a manager page similar with jkstatus or server-info, it is tomcat specific. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
