Re: adding features to Status servlet
to elaborate a bit more my thoughts on the kind of stats would be useful from a monitoring perspective * system load * system freeram * system total ram * system free ram * open connections * # of connections timed_wait I'm sure are other stats that are useful. A combination of the existing stats from the status servlet plus a few system stats should go a long way and make life a little bit easier. peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Peter Lin wrote: to elaborate a bit more my thoughts on the kind of stats would be useful from a monitoring perspective * system load * system freeram * system total ram * system free ram * open connections * # of connections timed_wait I'm sure are other stats that are useful. A combination of the existing stats from the status servlet plus a few system stats should go a long way and make life a little bit easier. For WINNT we can get: IdleTime, KernelTime, UserTime for each CPU on the system. Using NtQuerySystemInformation. GlobalMemoryStatus: dwMemoryLoad Approximate percentage of total physical memory that is in use. dwTotalPhys Total size of physical memory, in bytes. dwAvailPhys Size of physical memory available, in bytes. dwTotalPageFile Size of the committed memory limit, in bytes. dwAvailPageFile Size of available memory to commit, in bytes. dwTotalVirtual Total size of the user mode portion of the virtual address space of the calling process, in bytes. dwAvailVirtual Size of unreserved and uncommitted memory in the user mode portion of the virtual address space of the calling process, in bytes. We can get handle count (will see if it can be filtered for sockets only) for current process. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. peter On Sat, 01 Jan 2005 15:18:39 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Costin Manolache wrote: Well, I'm working over a year now on a project that I've called apr-java. This is a thin (for now) wrapper around apr and apr-utils, so it will be supported on all platforms the apr is. BTW - it would be really great if it would use the SWT model, i.e. JNI methods matching exactly the APR signatures and param types, with minimal ammount of C wrapper code. It works really well, and it's the easiest to maintain and fastest of all JNI flavors I've seen. Exactly. IMO the SWT from Eclipse proved to be as effective and easy to use as any other Java package or library. And that is what I have done with my apr-java. Right now I've implemented it using the org.apache.apr.native with the Library, Pool, Error, File, Mutex, Mmap, Shm, Socket and Pollset as containers for specific APR functions with exactly the same function prototypes. The wrapping code is really minimal, and in lot cases done as macros. I did not tried to wrap the code that has better or direct implementation in Java like string, thread, etc... Also the project does not prevent that we add any additional functionality not present in the APR. Mladen. - 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: adding features to Status servlet
Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
sysinfo on unix/linux should be pretty easy. I've used windows performance stats before when i tried to write the equivalent of the status servlet for IIS. I will try to write an exe named sysinfo that spits out similar performance stats. how can I help mladen? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - 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: adding features to Status servlet
For systems with a /proc file system with these statistics, this doesn't require any JNI ... -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 10:04 AM To: Tomcat Developers List Subject: Re: adding features to Status servlet sysinfo on unix/linux should be pretty easy. I've used windows performance stats before when i tried to write the equivalent of the status servlet for IIS. I will try to write an exe named sysinfo that spits out similar performance stats. how can I help mladen? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - 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]
Re: adding features to Status servlet
Mladen Turk 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. Well, I'm working over a year now on a project that I've called apr-java. This is a thin (for now) wrapper around apr and apr-utils, so it will be supported on all platforms the apr is. Things like true shared memory, process mutexes, advanced networking, pipes, etc. that are missing from the core Java will be supported. Usages are many, like writing high-performance networking connector for Tomcat, making Tomcat a Apache mpm-like server with multiple JVMs, etc... I hope I'll have a working start point this month, so we could discuss is it worth the effort at all, would it fit inside JTC, commons, or to go trough apache incubation as a separate project. I like that apr-java. It would be a useful basis for experimentation. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
hey mladen, is apr-java available in the normal APR distribution? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - 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: adding features to Status servlet
Why don't you check in some of this to j-t-c or some 'proposal' area ? AFAIK apr has a lot of functionality, but not everything is included. It would be nice if it is not limited to apr. Usually with JNI the hardest part is to build, distribute and then set it up and debug ld_library_path issues. If you do it for one library, it's easy to add more. Costin Mladen Turk wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Benson Margulies wrote: For systems with a /proc file system with these statistics, this doesn't require any JNI ... Yes, there are a lot of ways to workaround java limitations. /proc is one. But even on linux, a lot is not exposed via /proc, but ioctl. I guess the goal is not to implement sysinfo, but have a way to get more platform-specific information and access platform-specific features. Costin -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 10:04 AM To: Tomcat Developers List Subject: Re: adding features to Status servlet sysinfo on unix/linux should be pretty easy. I've used windows performance stats before when i tried to write the equivalent of the status servlet for IIS. I will try to write an exe named sysinfo that spits out similar performance stats. how can I help mladen? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - 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]
Re: adding features to Status servlet
So which way would be best/better to proceed? Since mladen has his apr-java stuff, would it make sense to do this? 1. write native windows dll 2. write apr component 3. use apr-java to wrap apr 4. wrap apr-java with mbeans or 1. write apr component to call system level API 2. use apr-java to wrap apr 3. wrap apr-java with mbeans or something completely different? peter On Mon, 03 Jan 2005 11:21:55 -0800, Costin Manolache [EMAIL PROTECTED] wrote: Benson Margulies wrote: For systems with a /proc file system with these statistics, this doesn't require any JNI ... Yes, there are a lot of ways to workaround java limitations. /proc is one. But even on linux, a lot is not exposed via /proc, but ioctl. I guess the goal is not to implement sysinfo, but have a way to get more platform-specific information and access platform-specific features. Costin -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 10:04 AM To: Tomcat Developers List Subject: Re: adding features to Status servlet sysinfo on unix/linux should be pretty easy. I've used windows performance stats before when i tried to write the equivalent of the status servlet for IIS. I will try to write an exe named sysinfo that spits out similar performance stats. how can I help mladen? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - 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]
Re: adding features to Status servlet
Or: 1. Wait for Mladen to check in the code 2. figure out how to build it and how to install it easily in tomcat ( and other java applications ). 3. probably add one native method. I don't think wrapping it as apr component makes sense ( apr is not a component system like xpcom ). 4. write the java mbean - using the native method and making all conversions between the native signature and java style ( if SWT-style of jni is used - i.e. using byte[], int pointers, etc - and doing java adaptation in java ). I'm as curious as you are to see the code and figure out how it can be used, I love jni :-) Costin Peter Lin wrote: So which way would be best/better to proceed? Since mladen has his apr-java stuff, would it make sense to do this? 1. write native windows dll 2. write apr component 3. use apr-java to wrap apr 4. wrap apr-java with mbeans or 1. write apr component to call system level API 2. use apr-java to wrap apr 3. wrap apr-java with mbeans or something completely different? peter On Mon, 03 Jan 2005 11:21:55 -0800, Costin Manolache [EMAIL PROTECTED] wrote: Benson Margulies wrote: For systems with a /proc file system with these statistics, this doesn't require any JNI ... Yes, there are a lot of ways to workaround java limitations. /proc is one. But even on linux, a lot is not exposed via /proc, but ioctl. I guess the goal is not to implement sysinfo, but have a way to get more platform-specific information and access platform-specific features. Costin -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 10:04 AM To: Tomcat Developers List Subject: Re: adding features to Status servlet sysinfo on unix/linux should be pretty easy. I've used windows performance stats before when i tried to write the equivalent of the status servlet for IIS. I will try to write an exe named sysinfo that spits out similar performance stats. how can I help mladen? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - 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]
Re: adding features to Status servlet
that sounds like a good idea :) look forward to trying it out once mladen checks in the code. peter On Mon, 03 Jan 2005 18:44:15 -0800, Costin Manolache [EMAIL PROTECTED] wrote: Or: 1. Wait for Mladen to check in the code 2. figure out how to build it and how to install it easily in tomcat ( and other java applications ). 3. probably add one native method. I don't think wrapping it as apr component makes sense ( apr is not a component system like xpcom ). 4. write the java mbean - using the native method and making all conversions between the native signature and java style ( if SWT-style of jni is used - i.e. using byte[], int pointers, etc - and doing java adaptation in java ). I'm as curious as you are to see the code and figure out how it can be used, I love jni :-) Costin Peter Lin wrote: So which way would be best/better to proceed? Since mladen has his apr-java stuff, would it make sense to do this? 1. write native windows dll 2. write apr component 3. use apr-java to wrap apr 4. wrap apr-java with mbeans or 1. write apr component to call system level API 2. use apr-java to wrap apr 3. wrap apr-java with mbeans or something completely different? peter On Mon, 03 Jan 2005 11:21:55 -0800, Costin Manolache [EMAIL PROTECTED] wrote: Benson Margulies wrote: For systems with a /proc file system with these statistics, this doesn't require any JNI ... Yes, there are a lot of ways to workaround java limitations. /proc is one. But even on linux, a lot is not exposed via /proc, but ioctl. I guess the goal is not to implement sysinfo, but have a way to get more platform-specific information and access platform-specific features. Costin -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 10:04 AM To: Tomcat Developers List Subject: Re: adding features to Status servlet sysinfo on unix/linux should be pretty easy. I've used windows performance stats before when i tried to write the equivalent of the status servlet for IIS. I will try to write an exe named sysinfo that spits out similar performance stats. how can I help mladen? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Peter Lin woolfel at gmail.com writes: that sounds like a good idea :) look forward to trying it out once mladen checks in the code. peter isn't what you are looking to do already available through the new 5.0 version jvm itself? startup tomcat with the additional jvm switch -Dcom.sun.management.jmxremote and then connect with your own custom MBean. to see what's possible, sun includes jconsole (a small gui app). it sure seems like everything you guys are talking about and more. Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
right it is available in JDK5, but not everyone can use jdk5 :( I know plenty of people who are still using jdk1.3.1 and plenty are just moving to jdk1.4.2 now. many of the features are available in jdk5, but I believe what mladen is working on is beyond what jdk5 provides. I've only looked at some of the new features in jdk5. I guess i could target jdk5, but it would be nice to have a solution that can work with jdk1.4.2. peter On Tue, 4 Jan 2005 03:49:49 + (UTC), Kevin Offet [EMAIL PROTECTED] wrote: Peter Lin woolfel at gmail.com writes: that sounds like a good idea :) look forward to trying it out once mladen checks in the code. peter isn't what you are looking to do already available through the new 5.0 version jvm itself? startup tomcat with the additional jvm switch -Dcom.sun.management.jmxremote and then connect with your own custom MBean. to see what's possible, sun includes jconsole (a small gui app). it sure seems like everything you guys are talking about and more. Kevin - 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: adding features to Status servlet
Peter Lin woolfel at gmail.com writes: right it is available in JDK5, but not everyone can use jdk5 :( I know plenty of people who are still using jdk1.3.1 and plenty are just moving to jdk1.4.2 now. many of the features are available in jdk5, but I believe what mladen is working on is beyond what jdk5 provides. I've only looked at some of the new features in jdk5. I guess i could target jdk5, but it would be nice to have a solution that can work with jdk1.4.2. peter if it were only a matter of which version of jdk one uses, i'd say that you were proposing a solution that would have a limited lifetime. [as an aside - monitoring features could be a strong motivation for people to upgrade, which would be a good thing ;-) ] but having a solution independent of any one VM (sun/ibm/whoever) or version is the best. i do have a cold, but that is no excuse for being too fast of fingers and too slow of brain. ;-) i've been lurking the list for a while now and just itching to find some place where i might be able to help. so if you find you could use a little help, please drop me a note. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
hehe, well if it was just a simple JNI calling sysinfo, I would agree it would have limited lifespan. But considering how slow some people move, it would last atleast 3-4 years, which is still useful in my mind. given that mladen is working on apr-java, I would say it is more useful and would have a significantly longer lifespan. everything has a life span, but if it is useful, than i feel it's worth while. plus it's my own time, so not like anyone else is going to care if it only lasts for 2-4 years. I much rather have the option of using it with jdk1.4 and across all VM's than simply relying on Sun's jdk5. peter On Tue, 4 Jan 2005 04:46:48 + (UTC), Kevin Offet [EMAIL PROTECTED] wrote: Peter Lin woolfel at gmail.com writes: right it is available in JDK5, but not everyone can use jdk5 :( I know plenty of people who are still using jdk1.3.1 and plenty are just moving to jdk1.4.2 now. many of the features are available in jdk5, but I believe what mladen is working on is beyond what jdk5 provides. I've only looked at some of the new features in jdk5. I guess i could target jdk5, but it would be nice to have a solution that can work with jdk1.4.2. peter if it were only a matter of which version of jdk one uses, i'd say that you were proposing a solution that would have a limited lifetime. [as an aside - monitoring features could be a strong motivation for people to upgrade, which would be a good thing ;-) ] but having a solution independent of any one VM (sun/ibm/whoever) or version is the best. i do have a cold, but that is no excuse for being too fast of fingers and too slow of brain. ;-) i've been lurking the list for a while now and just itching to find some place where i might be able to help. so if you find you could use a little help, please drop me a note. - 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: adding features to Status servlet
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. Well, I'm working over a year now on a project that I've called apr-java. This is a thin (for now) wrapper around apr and apr-utils, so it will be supported on all platforms the apr is. Things like true shared memory, process mutexes, advanced networking, pipes, etc. that are missing from the core Java will be supported. Usages are many, like writing high-performance networking connector for Tomcat, making Tomcat a Apache mpm-like server with multiple JVMs, etc... I hope I'll have a working start point this month, so we could discuss is it worth the effort at all, would it fit inside JTC, commons, or to go trough apache incubation as a separate project. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Mladen Turk 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. Well, I'm working over a year now on a project that I've called apr-java. This is a thin (for now) wrapper around apr and apr-utils, so it will be supported on all platforms the apr is. Things like true shared memory, process mutexes, advanced networking, pipes, etc. that are missing from the core Java will be supported. Usages are many, like writing high-performance networking connector for Tomcat, making Tomcat a Apache mpm-like server with multiple JVMs, etc... I hope I'll have a working start point this month, so we could discuss is it worth the effort at all, would it fit inside JTC, commons, or to go trough apache incubation as a separate project. Mladen. Anything that allows Java to do things only native apps can do instead of beeing as dumb as the dumbest platform is worth the effort :-) JTC already has some apr and jni code ( it is true, using the dead jk2 model ), why not start there and if it grows big enough move to commons? BTW - it would be really great if it would use the SWT model, i.e. JNI methods matching exactly the APR signatures and param types, with minimal ammount of C wrapper code. It works really well, and it's the easiest to maintain and fastest of all JNI flavors I've seen. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Costin Manolache wrote: Well, I'm working over a year now on a project that I've called apr-java. This is a thin (for now) wrapper around apr and apr-utils, so it will be supported on all platforms the apr is. BTW - it would be really great if it would use the SWT model, i.e. JNI methods matching exactly the APR signatures and param types, with minimal ammount of C wrapper code. It works really well, and it's the easiest to maintain and fastest of all JNI flavors I've seen. Exactly. IMO the SWT from Eclipse proved to be as effective and easy to use as any other Java package or library. And that is what I have done with my apr-java. Right now I've implemented it using the org.apache.apr.native with the Library, Pool, Error, File, Mutex, Mmap, Shm, Socket and Pollset as containers for specific APR functions with exactly the same function prototypes. The wrapping code is really minimal, and in lot cases done as macros. I did not tried to wrap the code that has better or direct implementation in Java like string, thread, etc... Also the project does not prevent that we add any additional functionality not present in the APR. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
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]
Re: adding features to Status servlet
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]
Re: adding features to Status servlet
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]
Re: adding features to Status servlet
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]
Re: adding features to Status servlet
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]
