Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
--- Jeff Genender [EMAIL PROTECTED] wrote: Anita Kulshreshtha wrote: I see Monitoring Console as a tool, a standard J2EE Application, that has been packaged for a convenient installation in Geronimo. It talks to a geronimo specific agent to discover and monitor a geronimo instance running elsewhere. I do not see it as an integral part of G, and hence prefer /plugins. Its location in svn does not affect the convenience of using it. It will always be installed from 'plugins' portlet and will be visible as an available plugin. IMHO, it should definitely be a plugin (as should everything we ship), but I think it should be a plugin that is installed by default. I hear y'all :) If the plugin has to be installed by default, server/trunk/plugin is the best place for it. I will be moving it to server/trunk/plugin/monitoring/mconsole and server/trunk/plugin/monitoring/agent Viet has been working on fixing problems discussed elsewhere in this thread. It will be wired into the main build when it is fairly stable. Thanks Anita As pointed out in another email, monitoring is typically shipped and active in some form for most other application servers. If most of the users find it helpful to have automatically enabled, then its probably good that we do so. I would probably suggest as we get closer to a release date that we get more input from users on this subject so we can make a proper and informed decision. Jeff Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 10, 2007, at 7:18 AM, Jeff Genender wrote: Anita Kulshreshtha wrote: I see Monitoring Console as a tool, a standard J2EE Application, that has been packaged for a convenient installation in Geronimo. It talks to a geronimo specific agent to discover and monitor a geronimo instance running elsewhere. I do not see it as an integral part of G, and hence prefer /plugins. Its location in svn does not affect the convenience of using it. It will always be installed from 'plugins' portlet and will be visible as an available plugin. IMHO, it should definitely be a plugin (as should everything we ship), but I think it should be a plugin that is installed by default. As pointed out in another email, monitoring is typically shipped and active in some form for most other application servers. If most of the users find it helpful to have automatically enabled, then its probably good that we do so. I would probably suggest as we get closer to a release date that we get more input from users on this subject so we can make a proper and informed decision. This reflects my sentiments as well. Regards, Alan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
--- Matt Hogstrom [EMAIL PROTECTED] wrote: On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote: 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I was thinking of plugins.. I'm not sure it really matters where the code goes in the interim. Plugins makes sense but I would move it to trunk first. Trunk is certainly viable and would likely get more people to look at the code, report issues, and most likely ooh and awe about cool looking graphs and statistics. If it turns out that the monitoring bloats the server in an unacceptable way, has incorrect statistics or consumes too many resources then I would think that moving it to plugins would be a reasonable approach. I see Monitoring Console as a tool, a standard J2EE Application, that has been packaged for a convenient installation in Geronimo. It talks to a geronimo specific agent to discover and monitor a geronimo instance running elsewhere. I do not see it as an integral part of G, and hence prefer /plugins. Its location in svn does not affect the convenience of using it. It will always be installed from 'plugins' portlet and will be visible as an available plugin. But that is just my opinion.. Thanks Anita Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
I'm with Matt on this. Since it is not perfect to everybody's satisfaction, let us move it to the /plugins tree (at least for now). Sandbox is definitely not the place for it. Erik, contrary to your belief, the /plugins tree does not contain only those plugins that work independent of G. It *mostly* contains plugins that integrate independent projects (like Liferay, ApacheDS, roller etc) with G. Now the monitoring plugin does not actually fit that bill. Neverthless, that is still a step above sandbox, and still on the road to trunk/plugins. It can still be released with 2.1 and still available in the plugins catalog for possible installation. Cheers Prasad On Dec 8, 2007 12:00 AM, Matt Hogstrom [EMAIL PROTECTED] wrote: On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote: 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I was thinking of plugins.. I'm not sure it really matters where the code goes in the interim. Plugins makes sense but I would move it to trunk first. Trunk is certainly viable and would likely get more people to look at the code, report issues, and most likely ooh and awe about cool looking graphs and statistics. If it turns out that the monitoring bloats the server in an unacceptable way, has incorrect statistics or consumes too many resources then I would think that moving it to plugins would be a reasonable approach.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 10, 2007, at 8:25 AM, Anita Kulshreshtha wrote: I see Monitoring Console as a tool, a standard J2EE Application, that has been packaged for a convenient installation in Geronimo. It talks to a geronimo specific agent to discover and monitor a geronimo instance running elsewhere. I do not see it as an integral part of G, and hence prefer /plugins. Its location in svn does not affect the convenience of using it. It will always be installed from 'plugins' portlet and will be visible as an available plugin. But that is just my opinion.. You make a good point. I think the correct decision would be what do the users want in terms of it being an integral part of what they do they would prefer to not go and install it but have it as part of the base install. I'd be ok with either approach. Most AppServers that I know of do ship their project with some minimal level of monitoring. Perhaps that is the JMXViewer. Although, I'd personally prefer the GUI of the console over the viewer but that is personal preferece.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Matt Hogstrom wrote: I think the correct decision would be what do the users want in terms of it being an integral part of what they do they would prefer to not go and install it but have it as part of the base install. I'd be ok with either approach. Most AppServers that I know of do ship their project with some minimal level of monitoring. Perhaps that is the JMXViewer. Although, I'd personally prefer the GUI of the console over the viewer but that is personal preferece. +1...these are my sentiments as well.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Anita Kulshreshtha wrote: I see Monitoring Console as a tool, a standard J2EE Application, that has been packaged for a convenient installation in Geronimo. It talks to a geronimo specific agent to discover and monitor a geronimo instance running elsewhere. I do not see it as an integral part of G, and hence prefer /plugins. Its location in svn does not affect the convenience of using it. It will always be installed from 'plugins' portlet and will be visible as an available plugin. IMHO, it should definitely be a plugin (as should everything we ship), but I think it should be a plugin that is installed by default. As pointed out in another email, monitoring is typically shipped and active in some form for most other application servers. If most of the users find it helpful to have automatically enabled, then its probably good that we do so. I would probably suggest as we get closer to a release date that we get more input from users on this subject so we can make a proper and informed decision. Jeff
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote: --- Kevan Miller [EMAIL PROTECTED] wrote: On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote: --- Viet Nguyen [EMAIL PROTECTED] wrote: On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Eric, . Perhaps I am not making it clear. The graph that is shown as requestTime for tomcatWebConnector is incorrect. The value returned by tomcat is count not time. We need to have different methods to generate graphs for TimeStatistics, RangeStatistics, and BoundedRangeStatistics. OK. That's good information. But a very important one for a user who takes the trouble to install the plugins and reads the document about monitoring and statistics. But, IMO, that doesn't necessarily mean we shouldn't move the monitoring plugin out of sandbox. It might mean that we aren't ready to *release* the monitoring plugin. I don't think we're having a *release* discussion -- at least we shouldn't be. If the plugin is moved to trunk, as the title of the discussion says, does it not get automatically released? It would be released *when* we release the code in trunk (in this case with Geronimo 2.1). Until we release, it's under development just like the rest of the server (and subject to change). We can have the discussion that we don't want to hold up a Geronimo 2.1 release waiting for monitoring plugin problems to be resolved, but I'd prefer we discuss without a particular timeline in mind... IMO, we have the following questions to answer: 1. Are we ready to move monitoring plugin out of sandbox? yes 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I was thinking of plugins.. 3. What bug fixes/new features need to be added to the monitoring plugin before it's ready to be released? We should do the minimum and make sure all the information that is displayed is correct, i.e. there is no discrepancy between the raw value (displayed on the console) and the graph. We can address the fact the values themselves are skewed later. OK. Sounds good. I see you've been generating jira's against the admin console. I assume they are recording the functions that need to be fixed? --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
--- Kevan Miller [EMAIL PROTECTED] wrote: On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote: --- Viet Nguyen [EMAIL PROTECTED] wrote: On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Eric, . Perhaps I am not making it clear. The graph that is shown as requestTime for tomcatWebConnector is incorrect. The value returned by tomcat is count not time. We need to have different methods to generate graphs for TimeStatistics, RangeStatistics, and BoundedRangeStatistics. OK. That's good information. But a very important one for a user who takes the trouble to install the plugins and reads the document about monitoring and statistics. But, IMO, that doesn't necessarily mean we shouldn't move the monitoring plugin out of sandbox. It might mean that we aren't ready to *release* the monitoring plugin. I don't think we're having a *release* discussion -- at least we shouldn't be. If the plugin is moved to trunk, as the title of the discussion says, does it not get automatically released? We can have the discussion that we don't want to hold up a Geronimo 2.1 release waiting for monitoring plugin problems to be resolved, but I'd prefer we discuss without a particular timeline in mind... IMO, we have the following questions to answer: 1. Are we ready to move monitoring plugin out of sandbox? yes 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I was thinking of plugins.. 3. What bug fixes/new features need to be added to the monitoring plugin before it's ready to be released? We should do the minimum and make sure all the information that is displayed is correct, i.e. there is no discrepancy between the raw value (displayed on the console) and the graph. We can address the fact the values themselves are skewed later. Thanks Anita Anita, Your objections seem to be in category 3, but I may be wrong. So, help us understand what you're thinking... --kevan Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
We definitely need such an adapter interface. This will allow us to not corrupt the target instance, e.g. a minimal server, by installing openejb. Thanks Anita --- Jeff Genender [EMAIL PROTECTED] wrote: So I think we are kind of caught in a catch 22 here... The issue is, the server is pluggable for the most part. People may/may not want EJB, but definitely want the management capabilities. Whats your thought on an adapter interface that provides for full JSR-77 compatibility, thus requiring EJB, or a switch that allows for pure JMX remoting? This would allow for compliance or be able to leverage the management without EJB if so desired. Thoughts? Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 12:45 PM, Viet Nguyen wrote: There are goods and bads to both sides to this. If we strictly follow JSR 77, which means we will use MEJB and are forced to have OpenEJB as a pre-req, we won't have to worry if our architecture is good or not (I hope this is right), because we're following a standard for monitoring and management. On the flip side, if we use JMX to get a hold of the statistics, we will be able to monitor any type of server. I'm aware that some commercial servers make sure that they support JSR-77 as they have to. Unfortunately, JSR-77 can be heavy and the commercial servers, *they who must not be named*, use lighter weight stuff under the covers and use their statistics for monitoring and make JSR-77 available for those that want to code to it. JSR-77 is a required implementation but not the only way to do it.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote: 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I was thinking of plugins.. I'm not sure it really matters where the code goes in the interim. Plugins makes sense but I would move it to trunk first. Trunk is certainly viable and would likely get more people to look at the code, report issues, and most likely ooh and awe about cool looking graphs and statistics. If it turns out that the monitoring bloats the server in an unacceptable way, has incorrect statistics or consumes too many resources then I would think that moving it to plugins would be a reasonable approach.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Kevan Miller wrote: OK. That's good information. But, IMO, that doesn't necessarily mean we shouldn't move the monitoring plugin out of sandbox. It might mean that we aren't ready to *release* the monitoring plugin. I don't think we're having a *release* discussion -- at least we shouldn't be. We can have the discussion that we don't want to hold up a Geronimo 2.1 release waiting for monitoring plugin problems to be resolved, but I'd prefer we discuss without a particular timeline in mind... IMO, we have the following questions to answer: 1. Are we ready to move monitoring plugin out of sandbox? Yes, I definitely believe so, although I might be marginally biased =P 2. If yes, then where should we move it to? Should it be in server/trunk/plugins or should the monitoring plugin be a subproject. I was thinking server/trunk/plugins myself... the only other option would be just straight plugins... however, correct me if I'm wrong on this, but I believe just /plugins is more for things that can be used independent of geronimo... which is definitely not the case for the monitoring plugin currently. 3. What bug fixes/new features need to be added to the monitoring plugin before it's ready to be released? The single biggest thing on my mind for this currently is the new graphing engine that I mentioned, but whether or not it's part of server/trunk/plugins has no bearing on this getting done. Anita, Your objections seem to be in category 3, but I may be wrong. So, help us understand what you're thinking... --kevan Thanks, Erik B. Craig [EMAIL PROTECTED]
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007 5:43 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Don't I get 24 hours to respond :) Yes, you *did* ;-) It passed. Seriously, I'm in favor releasing what we've got so far as that's the best way to get people (end users and us) engaged in the development process of the monitoring plugin. It's not ideal, but if there're people who believe it serves well in some use cases let the puppy go out and see the sun ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
--- Viet Nguyen [EMAIL PROTECTED] wrote: On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Eric, For this discussion I will use MC for monitoring console (aka client), and agent for mrc-server. It is possible to use 3 G instances (I used this method until GERONIMO-3660). G1 with MC on remote or local m/c, G2 with agent on local m/c, and G3 the instance to be monitored. This is the ideal solution but will be most difficult to implement efficiently. The advantage is that the instance to be monitored is not corrupted in any way. The second option is to use 2 G instances. G1 with MC on remote or local m/c, G2 the instance to be monitored. The agent is loaded in G2. This is what we have now. we need to reduce DB activity. We can improve upon this as we go. The TimeSatistics has 4 values named count, max, min and totaltime. The graph treats count as the current value of time. This is because the information that it is a TimeStatistics is lost in the DB. All four values appear as separate statistics, and the graph would draw each one separately as value, min, max! The same is true for BoundedRangeStatistics. A single graph should show all 5 values. More inline.. The current implementation only allows for one statistic to be shown at a time on a graph, but if you wanted to have the max or min statistics that could be easily obtained since those numbers are there. I think allowing the admin to graph all 4 values on the same graph is a very useful feature and should definitely be added; However, this is not necessarily a stop ship issue. Perhaps I am not making it clear. The graph that is shown as requestTime for tomcatWebConnector is incorrect. The value returned by tomcat is count not time. We need to have different methods to generate graphs for TimeStatistics, RangeStatistics, and BoundedRangeStatistics. Thanks Anita --- Erik B. Craig [EMAIL PROTECTED] wrote: Anita, You mentioned that the collecting agent running within the same jvm (I.E. under a Geronimo instance being monitored as a plugin) is an issue due to resource consumption... however I am unsure what a good alternative approach would be? Are you suggesting we have a separate instance of G to monitor a target instance? Or are you suggesting that the mrc-server be a standalone java app that runs in it's own JVM? This is a possibility too.. Currently the graph builder will plot any data being grabbed as snapshots in any method defined by the user. In the current graph creation page, the user has the option to differentiate between raw count vs. count/time or even count/some other count. There are a lot of options configurable by the user. When I added ErrorCount and ErrorCount/sec graphs to a single view, The other views got corrupted. This is a minor issue and can be easily fixed. Thanks Anita Additionally... do you have an example of the graphs for TimeStatistics or BoundedRangeStatistics being wrong/how they are wrong? Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
I am still unsure of why having the monitoring plugin in trunk is such a bad thing. It is in no way a perfect solution, but once it's in trunk we can engage users and other devs to better it. I do not see any dominating issues that should keep this plugin outside of trunk. Should we vote for this? Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 5, 2007, at 11:43 PM, Anita Kulshreshtha wrote: Anita, can you please technically show why this is not ready or should not be released? Can you explain/show where the graphs are wrong? This may help move things along. Jeff Don't I get 24 hours to respond :) We've got lot's of time to discuss. Jeff was just eager to understand what your concerns are... --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 12:01 PM, Viet Nguyen wrote: I am still unsure of why having the monitoring plugin in trunk is such a bad thing. It is in no way a perfect solution, but once it's in trunk we can engage users and other devs to better it. I do not see any dominating issues that should keep this plugin outside of trunk. Should we vote for this? No we shouldn't vote... Not while we're discussing the issue. Possible that there may be a vote later. Just as likely that we'll find a consensus. Let's make sure we understand each other, first. --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 1:27 AM, Viet Nguyen wrote: On Dec 5, 2007 9:23 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Dec 5, 2007, at 9:07 PM, David Jencks wrote: On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote: Viet, Thanks for working on the monitoring console. A lot still remains to be done. There are architectural issues which need to be addressed: Currently the agent (aka mrc-server) needs to reside in same jvm as the server being monitored. It consumes significant DB resources. While this might not be ideal (I don't know one way or another) does this make it useless? I'd be in favor of getting something out with some useful functionality now, and improving it as it gets used. I tend to agree. I'd like to give it a whirl. Erik/Viet are the installation instructions? The installation is pretty simple. Since everything is packaged into plugins there are two ways to do it. 1a. Just install the bundled (has both server and client) pluginit is monitor-tomcat/monitor-jetty 1b. Install the client plugin on a monitoring machine and the mrc-server on the server to be monitored. 2. Then you add the server to the list of monitored machines via the portlet You mention MEJB connections. Can you help me understand where the MEJB is running? The local server or the remote servers? The MEJB connections are done on the remote servers (those that are being monitored with the collecting agent). The collecting agent authenticates itself by having the client pass in the credentials. Then this collecting agent acts as the thin layer between the client and the MEJB, with additional functionality. So, remote servers must have OpenEJB installed? Hmmm. It be really nice to monitor any Geronimo server... Why aren't we using JMX? Perhaps I'm missing something? If that's what we have, that's what we have... Just trying to be sure I understand... --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Yes, with the current implementation we have, OpenEJB is a prerequisite. JMX is a good solution too, but I wanted to follow the JSR 77 spec, which tells us to communicate with the server through the usage of MEJB, which is why OpenEJB is needed in this case. --Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Isn't the JSR 77 spec JMX based? Jeff Viet Nguyen wrote: Yes, with the current implementation we have, OpenEJB is a prerequisite. JMX is a good solution too, but I wanted to follow the JSR 77 spec, which tells us to communicate with the server through the usage of MEJB, which is why OpenEJB is needed in this case. --Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Never mind...yes looks like MEJB is a requirement. Jeff Jeff Genender wrote: Isn't the JSR 77 spec JMX based? Jeff Viet Nguyen wrote: Yes, with the current implementation we have, OpenEJB is a prerequisite. JMX is a good solution too, but I wanted to follow the JSR 77 spec, which tells us to communicate with the server through the usage of MEJB, which is why OpenEJB is needed in this case. --Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
So I think we are kind of caught in a catch 22 here... The issue is, the server is pluggable for the most part. People may/may not want EJB, but definitely want the management capabilities. Whats your thought on an adapter interface that provides for full JSR-77 compatibility, thus requiring EJB, or a switch that allows for pure JMX remoting? This would allow for compliance or be able to leverage the management without EJB if so desired. Thoughts? Viet Nguyen wrote: Yes, with the current implementation we have, OpenEJB is a prerequisite. JMX is a good solution too, but I wanted to follow the JSR 77 spec, which tells us to communicate with the server through the usage of MEJB, which is why OpenEJB is needed in this case. --Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote: --- Viet Nguyen [EMAIL PROTECTED] wrote: On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Eric, For this discussion I will use MC for monitoring console (aka client), and agent for mrc-server. It is possible to use 3 G instances (I used this method until GERONIMO-3660). G1 with MC on remote or local m/c, G2 with agent on local m/c, and G3 the instance to be monitored. This is the ideal solution but will be most difficult to implement efficiently. The advantage is that the instance to be monitored is not corrupted in any way. The second option is to use 2 G instances. G1 with MC on remote or local m/c, G2 the instance to be monitored. The agent is loaded in G2. This is what we have now. we need to reduce DB activity. We can improve upon this as we go. The TimeSatistics has 4 values named count, max, min and totaltime. The graph treats count as the current value of time. This is because the information that it is a TimeStatistics is lost in the DB. All four values appear as separate statistics, and the graph would draw each one separately as value, min, max! The same is true for BoundedRangeStatistics. A single graph should show all 5 values. More inline.. The current implementation only allows for one statistic to be shown at a time on a graph, but if you wanted to have the max or min statistics that could be easily obtained since those numbers are there. I think allowing the admin to graph all 4 values on the same graph is a very useful feature and should definitely be added; However, this is not necessarily a stop ship issue. Perhaps I am not making it clear. The graph that is shown as requestTime for tomcatWebConnector is incorrect. The value returned by tomcat is count not time. We need to have different methods to generate graphs for TimeStatistics, RangeStatistics, and BoundedRangeStatistics. OK. That's good information. But, IMO, that doesn't necessarily mean we shouldn't move the monitoring plugin out of sandbox. It might mean that we aren't ready to *release* the monitoring plugin. I don't think we're having a *release* discussion -- at least we shouldn't be. We can have the discussion that we don't want to hold up a Geronimo 2.1 release waiting for monitoring plugin problems to be resolved, but I'd prefer we discuss without a particular timeline in mind... IMO, we have the following questions to answer: 1. Are we ready to move monitoring plugin out of sandbox? 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. 3. What bug fixes/new features need to be added to the monitoring plugin before it's ready to be released? Anita, Your objections seem to be in category 3, but I may be wrong. So, help us understand what you're thinking... --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Whats your thought on an adapter interface that provides for full JSR-77 compatibility, thus requiring EJB, or a switch that allows for pure JMX remoting? This would allow for compliance or be able to leverage the management without EJB if so desired. Thoughts? There are goods and bads to both sides to this. If we strictly follow JSR 77, which means we will use MEJB and are forced to have OpenEJB as a pre-req, we won't have to worry if our architecture is good or not (I hope this is right), because we're following a standard for monitoring and management. On the flip side, if we use JMX to get a hold of the statistics, we will be able to monitor any type of server. Doesn't necessarily have to be a Geronimo server either, as long as we can connect to it via JMX, which I think is a huge plus. With that said, I think if we decide to take the alternative JMX path, it can be changed later (even though this was originally how we implemented it). I think the important thing now, is to determine whether or not the monitoring plugin merits a place in trunk.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
I certainly believe it deserves a spot in trunk...this is an enhancement to what we don't have before. That's progress...and its pretty darn cool too ;-) I definitely don't want my ideas to hold up its movement...just food for thought for down the road. Jeff Viet Nguyen wrote: Whats your thought on an adapter interface that provides for full JSR-77 compatibility, thus requiring EJB, or a switch that allows for pure JMX remoting? This would allow for compliance or be able to leverage the management without EJB if so desired. Thoughts? There are goods and bads to both sides to this. If we strictly follow JSR 77, which means we will use MEJB and are forced to have OpenEJB as a pre-req, we won't have to worry if our architecture is good or not (I hope this is right), because we're following a standard for monitoring and management. On the flip side, if we use JMX to get a hold of the statistics, we will be able to monitor any type of server. Doesn't necessarily have to be a Geronimo server either, as long as we can connect to it via JMX, which I think is a huge plus. With that said, I think if we decide to take the alternative JMX path, it can be changed later (even though this was originally how we implemented it). I think the important thing now, is to determine whether or not the monitoring plugin merits a place in trunk.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 10:06 AM, Paul McMahan wrote: On Dec 6, 2007, at 12:45 PM, Kevan Miller wrote: 1. Are we ready to move monitoring plugin out of sandbox? +1 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I would vote for server/trunk/plugins, if for no other reason than to synchronize the monitoring plugin release with the server release. When the plugin gets to be more mature and can support multiple versions of geronimo then maybe we would consider moving it to a separate subproject. Also, moving it to trunk ensures that it will be included in the plugin catalog (~/.m2/repo/geronimo- plugins.xml) when you build trunk and will make it very easy to add monitoring to an assembly by just editing that assembly's pom. I don't have a strong opinion yet on where this should go, but I'd like to point out that any plugin you build with the car-maven- plugin, such as the roller or apacheds plugins, will have its metadata added to your local maven repo's geronimo-plugins.xml catalog. Similarly, no matter where the plugin is in svn, you can add it to a maven-built assembly by editing the assemblies pom. thanks david jencks 3. What bug fixes/new features need to be added to the monitoring plugin before it's ready to be released? I agree with Anita that it will need some testing feedback before releasing to the wild. IMO the best way to facilitate that type of exposure is to move it into trunk. I think that this new monitoring feature is important enough to justify holding up a 2.1 release if it actually comes down to that. Best wishes, Paul
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 12:45 PM, Kevan Miller wrote: 1. Are we ready to move monitoring plugin out of sandbox? +1 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I would vote for server/trunk/plugins, if for no other reason than to synchronize the monitoring plugin release with the server release. When the plugin gets to be more mature and can support multiple versions of geronimo then maybe we would consider moving it to a separate subproject. Also, moving it to trunk ensures that it will be included in the plugin catalog (~/.m2/repo/geronimo- plugins.xml) when you build trunk and will make it very easy to add monitoring to an assembly by just editing that assembly's pom. 3. What bug fixes/new features need to be added to the monitoring plugin before it's ready to be released? I agree with Anita that it will need some testing feedback before releasing to the wild. IMO the best way to facilitate that type of exposure is to move it into trunk. I think that this new monitoring feature is important enough to justify holding up a 2.1 release if it actually comes down to that. Best wishes, Paul
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
+1 Jacek On Dec 5, 2007 10:36 PM, Viet Nguyen [EMAIL PROTECTED] wrote: Hi All, There has been a lot of work done on the monitoring plugin lately. I think it is now time to move it from sandbox into trunk, in time for the 2.1 release. I am unsure of the timeline for 2.1, but I feel as though the monitoring plugin should be moved to trunk around this time, so that the little kinks can be worked out before it is too late for the release. Erik and I have worked together along with the help of many others to provide a monitoring collecting agent and monitoring portlet. To briefly go over what the monitoring plugin can do: -monitor multiple servers -securely connects to remote servers that are monitored (via MEJB and encryption of the password using Geronimo's EncryptionManager) -keeps an on going history of user-chosen statistics -provides the ability to view current and past statistics -customizable graphs (e.g. I can choose which stats I want to graph, and much more) -the ability to group certain graphs together into what we call a view. The idea is to allow an administrator to view only those graphs that he cares about...all in one place! -editable server, graphs, and views option -provides the ability to keep track of any mbean that is declared as a StatisticsProvider -administrator can custom define the elapsed time period before each snapshot is taken -everything is packaged into plugins (separate plugins and a bundled plugin with both pieces), so deploying is made easier I hope that some of you can take some time to test out the plugin which can be pulled from sandbox at http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and provide some feedback. If there are no objections, I hope that a committer can soon move the monitoring plugin into trunk. One of the new features that I would like to see listed for the 2.1 release is this monitoring plugin. I believe it will attract a lot of attention and users. Thanks, Viet -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
+1 I am definitely in favor of this, and would also like to see this make it to trunk before the 2.1 branch occurs. It would be great if we could get a few extra pairs of eyes to take a look at things and make sure it's all peachy. Thanks, Erik B. Craig [EMAIL PROTECTED] Viet Nguyen wrote: Hi All, There has been a lot of work done on the monitoring plugin lately. I think it is now time to move it from sandbox into trunk, in time for the 2.1 release. I am unsure of the timeline for 2.1, but I feel as though the monitoring plugin should be moved to trunk around this time, so that the little kinks can be worked out before it is too late for the release. Erik and I have worked together along with the help of many others to provide a monitoring collecting agent and monitoring portlet. To briefly go over what the monitoring plugin can do: -monitor multiple servers -securely connects to remote servers that are monitored (via MEJB and encryption of the password using Geronimo's EncryptionManager) -keeps an on going history of user-chosen statistics -provides the ability to view current and past statistics -customizable graphs (e.g. I can choose which stats I want to graph, and much more) -the ability to group certain graphs together into what we call a view. The idea is to allow an administrator to view only those graphs that he cares about...all in one place! -editable server, graphs, and views option -provides the ability to keep track of any mbean that is declared as a StatisticsProvider -administrator can custom define the elapsed time period before each snapshot is taken -everything is packaged into plugins (separate plugins and a bundled plugin with both pieces), so deploying is made easier I hope that some of you can take some time to test out the plugin which can be pulled from sandbox at http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and provide some feedback. If there are no objections, I hope that a committer can soon move the monitoring plugin into trunk. One of the new features that I would like to see listed for the 2.1 release is this monitoring plugin. I believe it will attract a lot of attention and users. Thanks, Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Anita, You mentioned that the collecting agent running within the same jvm (I.E. under a Geronimo instance being monitored as a plugin) is an issue due to resource consumption... however I am unsure what a good alternative approach would be? Are you suggesting we have a separate instance of G to monitor a target instance? Or are you suggesting that the mrc-server be a standalone java app that runs in it's own JVM? Currently the graph builder will plot any data being grabbed as snapshots in any method defined by the user. In the current graph creation page, the user has the option to differentiate between raw count vs. count/time or even count/some other count. There are a lot of options configurable by the user. Additionally... do you have an example of the graphs for TimeStatistics or BoundedRangeStatistics being wrong/how they are wrong? On Dec 5, 2007, at 7:29 PM, Anita Kulshreshtha wrote: Viet, Thanks for working on the monitoring console. A lot still remains to be done. There are architectural issues which need to be addressed: Currently the agent (aka mrc-server) needs to reside in same jvm as the server being monitored. It consumes significant DB resources. The Graph builder plots CountStatistics correctly. It does not provide a way (minor point) to choose/plot both the raw count and the throughput, i.e. count/sec. The graphs for TimeStatistics and BoundedRangeStatistics are wrong. This is a serious shortcoming. I would like it to be fixed before we can talk about releasing it. Thanks Anita --- Viet Nguyen [EMAIL PROTECTED] wrote: Hi All, There has been a lot of work done on the monitoring plugin lately. I think it is now time to move it from sandbox into trunk, in time for the 2.1 release. I am unsure of the timeline for 2.1, but I feel as though the monitoring plugin should be moved to trunk around this time, so that the little kinks can be worked out before it is too late for the release. Erik and I have worked together along with the help of many others to provide a monitoring collecting agent and monitoring portlet. To briefly go over what the monitoring plugin can do: -monitor multiple servers -securely connects to remote servers that are monitored (via MEJB and encryption of the password using Geronimo's EncryptionManager) -keeps an on going history of user-chosen statistics -provides the ability to view current and past statistics -customizable graphs (e.g. I can choose which stats I want to graph, and much more) -the ability to group certain graphs together into what we call a view. The idea is to allow an administrator to view only those graphs that he cares about...all in one place! -editable server, graphs, and views option -provides the ability to keep track of any mbean that is declared as a StatisticsProvider -administrator can custom define the elapsed time period before each snapshot is taken -everything is packaged into plugins (separate plugins and a bundled plugin with both pieces), so deploying is made easier I hope that some of you can take some time to test out the plugin which can be pulled from sandbox at http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and provide some feedback. If there are no objections, I hope that a committer can soon move the monitoring plugin into trunk. One of the new features that I would like to see listed for the 2.1 release is this monitoring plugin. I believe it will attract a lot of attention and users. Thanks, Viet Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Viet, Thanks for working on the monitoring console. A lot still remains to be done. There are architectural issues which need to be addressed: Currently the agent (aka mrc-server) needs to reside in same jvm as the server being monitored. It consumes significant DB resources. The Graph builder plots CountStatistics correctly. It does not provide a way (minor point) to choose/plot both the raw count and the throughput, i.e. count/sec. The graphs for TimeStatistics and BoundedRangeStatistics are wrong. This is a serious shortcoming. I would like it to be fixed before we can talk about releasing it. Thanks Anita --- Viet Nguyen [EMAIL PROTECTED] wrote: Hi All, There has been a lot of work done on the monitoring plugin lately. I think it is now time to move it from sandbox into trunk, in time for the 2.1 release. I am unsure of the timeline for 2.1, but I feel as though the monitoring plugin should be moved to trunk around this time, so that the little kinks can be worked out before it is too late for the release. Erik and I have worked together along with the help of many others to provide a monitoring collecting agent and monitoring portlet. To briefly go over what the monitoring plugin can do: -monitor multiple servers -securely connects to remote servers that are monitored (via MEJB and encryption of the password using Geronimo's EncryptionManager) -keeps an on going history of user-chosen statistics -provides the ability to view current and past statistics -customizable graphs (e.g. I can choose which stats I want to graph, and much more) -the ability to group certain graphs together into what we call a view. The idea is to allow an administrator to view only those graphs that he cares about...all in one place! -editable server, graphs, and views option -provides the ability to keep track of any mbean that is declared as a StatisticsProvider -administrator can custom define the elapsed time period before each snapshot is taken -everything is packaged into plugins (separate plugins and a bundled plugin with both pieces), so deploying is made easier I hope that some of you can take some time to test out the plugin which can be pulled from sandbox at http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and provide some feedback. If there are no objections, I hope that a committer can soon move the monitoring plugin into trunk. One of the new features that I would like to see listed for the 2.1 release is this monitoring plugin. I believe it will attract a lot of attention and users. Thanks, Viet Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote: Viet, Thanks for working on the monitoring console. A lot still remains to be done. There are architectural issues which need to be addressed: Currently the agent (aka mrc-server) needs to reside in same jvm as the server being monitored. It consumes significant DB resources. While this might not be ideal (I don't know one way or another) does this make it useless? I'd be in favor of getting something out with some useful functionality now, and improving it as it gets used. thanks david jencks The Graph builder plots CountStatistics correctly. It does not provide a way (minor point) to choose/plot both the raw count and the throughput, i.e. count/sec. The graphs for TimeStatistics and BoundedRangeStatistics are wrong. This is a serious shortcoming. I would like it to be fixed before we can talk about releasing it. Thanks Anita --- Viet Nguyen [EMAIL PROTECTED] wrote: Hi All, There has been a lot of work done on the monitoring plugin lately. I think it is now time to move it from sandbox into trunk, in time for the 2.1 release. I am unsure of the timeline for 2.1, but I feel as though the monitoring plugin should be moved to trunk around this time, so that the little kinks can be worked out before it is too late for the release. Erik and I have worked together along with the help of many others to provide a monitoring collecting agent and monitoring portlet. To briefly go over what the monitoring plugin can do: -monitor multiple servers -securely connects to remote servers that are monitored (via MEJB and encryption of the password using Geronimo's EncryptionManager) -keeps an on going history of user-chosen statistics -provides the ability to view current and past statistics -customizable graphs (e.g. I can choose which stats I want to graph, and much more) -the ability to group certain graphs together into what we call a view. The idea is to allow an administrator to view only those graphs that he cares about...all in one place! -editable server, graphs, and views option -provides the ability to keep track of any mbean that is declared as a StatisticsProvider -administrator can custom define the elapsed time period before each snapshot is taken -everything is packaged into plugins (separate plugins and a bundled plugin with both pieces), so deploying is made easier I hope that some of you can take some time to test out the plugin which can be pulled from sandbox at http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and provide some feedback. If there are no objections, I hope that a committer can soon move the monitoring plugin into trunk. One of the new features that I would like to see listed for the 2.1 release is this monitoring plugin. I believe it will attract a lot of attention and users. Thanks, Viet __ __ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/ newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
David Jencks wrote: On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote: Viet, Thanks for working on the monitoring console. A lot still remains to be done. There are architectural issues which need to be addressed: Currently the agent (aka mrc-server) needs to reside in same jvm as the server being monitored. It consumes significant DB resources. While this might not be ideal (I don't know one way or another) does this make it useless? I'd be in favor of getting something out with some useful functionality now, and improving it as it gets used. I was going to say the same but you beat me to it. +1 with your comment...new functionality is the way to go on this. This is a huge step in the right direction and gives the user more power than they had before. It may not be perfect but it certainly is wickedly cool ;-) Anita, can you please technically show why this is not ready or should not be released? Can you explain/show where the graphs are wrong? This may help move things along. Jeff thanks david jencks The Graph builder plots CountStatistics correctly. It does not provide a way (minor point) to choose/plot both the raw count and the throughput, i.e. count/sec. The graphs for TimeStatistics and BoundedRangeStatistics are wrong. This is a serious shortcoming. I would like it to be fixed before we can talk about releasing it. Thanks Anita --- Viet Nguyen [EMAIL PROTECTED] wrote: Hi All, There has been a lot of work done on the monitoring plugin lately. I think it is now time to move it from sandbox into trunk, in time for the 2.1 release. I am unsure of the timeline for 2.1, but I feel as though the monitoring plugin should be moved to trunk around this time, so that the little kinks can be worked out before it is too late for the release. Erik and I have worked together along with the help of many others to provide a monitoring collecting agent and monitoring portlet. To briefly go over what the monitoring plugin can do: -monitor multiple servers -securely connects to remote servers that are monitored (via MEJB and encryption of the password using Geronimo's EncryptionManager) -keeps an on going history of user-chosen statistics -provides the ability to view current and past statistics -customizable graphs (e.g. I can choose which stats I want to graph, and much more) -the ability to group certain graphs together into what we call a view. The idea is to allow an administrator to view only those graphs that he cares about...all in one place! -editable server, graphs, and views option -provides the ability to keep track of any mbean that is declared as a StatisticsProvider -administrator can custom define the elapsed time period before each snapshot is taken -everything is packaged into plugins (separate plugins and a bundled plugin with both pieces), so deploying is made easier I hope that some of you can take some time to test out the plugin which can be pulled from sandbox at http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and provide some feedback. If there are no objections, I hope that a committer can soon move the monitoring plugin into trunk. One of the new features that I would like to see listed for the 2.1 release is this monitoring plugin. I believe it will attract a lot of attention and users. Thanks, Viet Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 5, 2007, at 9:07 PM, David Jencks wrote: On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote: Viet, Thanks for working on the monitoring console. A lot still remains to be done. There are architectural issues which need to be addressed: Currently the agent (aka mrc-server) needs to reside in same jvm as the server being monitored. It consumes significant DB resources. While this might not be ideal (I don't know one way or another) does this make it useless? I'd be in favor of getting something out with some useful functionality now, and improving it as it gets used. I tend to agree. I'd like to give it a whirl. Erik/Viet are the installation instructions? You mention MEJB connections. Can you help me understand where the MEJB is running? The local server or the remote servers? --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Eric, For this discussion I will use MC for monitoring console (aka client), and agent for mrc-server. It is possible to use 3 G instances (I used this method until GERONIMO-3660). G1 with MC on remote or local m/c, G2 with agent on local m/c, and G3 the instance to be monitored. This is the ideal solution but will be most difficult to implement efficiently. The advantage is that the instance to be monitored is not corrupted in any way. The second option is to use 2 G instances. G1 with MC on remote or local m/c, G2 the instance to be monitored. The agent is loaded in G2. This is what we have now. we need to reduce DB activity. We can improve upon this as we go. The TimeSatistics has 4 values named count, max, min and totaltime. The graph treats count as the current value of time. This is because the information that it is a TimeStatistics is lost in the DB. All four values appear as separate statistics, and the graph would draw each one separately as value, min, max! The same is true for BoundedRangeStatistics. A single graph should show all 5 values. More inline.. --- Erik B. Craig [EMAIL PROTECTED] wrote: Anita, You mentioned that the collecting agent running within the same jvm (I.E. under a Geronimo instance being monitored as a plugin) is an issue due to resource consumption... however I am unsure what a good alternative approach would be? Are you suggesting we have a separate instance of G to monitor a target instance? Or are you suggesting that the mrc-server be a standalone java app that runs in it's own JVM? This is a possibility too.. Currently the graph builder will plot any data being grabbed as snapshots in any method defined by the user. In the current graph creation page, the user has the option to differentiate between raw count vs. count/time or even count/some other count. There are a lot of options configurable by the user. When I added ErrorCount and ErrorCount/sec graphs to a single view, The other views got corrupted. This is a minor issue and can be easily fixed. Thanks Anita Additionally... do you have an example of the graphs for TimeStatistics or BoundedRangeStatistics being wrong/how they are wrong? Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Anita, can you please technically show why this is not ready or should not be released? Can you explain/show where the graphs are wrong? This may help move things along. Jeff Don't I get 24 hours to respond :) Thanks Anita Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 5, 2007 9:23 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Dec 5, 2007, at 9:07 PM, David Jencks wrote: On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote: Viet, Thanks for working on the monitoring console. A lot still remains to be done. There are architectural issues which need to be addressed: Currently the agent (aka mrc-server) needs to reside in same jvm as the server being monitored. It consumes significant DB resources. While this might not be ideal (I don't know one way or another) does this make it useless? I'd be in favor of getting something out with some useful functionality now, and improving it as it gets used. I tend to agree. I'd like to give it a whirl. Erik/Viet are the installation instructions? The installation is pretty simple. Since everything is packaged into plugins there are two ways to do it. 1a. Just install the bundled (has both server and client) pluginit is monitor-tomcat/monitor-jetty 1b. Install the client plugin on a monitoring machine and the mrc-server on the server to be monitored. 2. Then you add the server to the list of monitored machines via the portlet You mention MEJB connections. Can you help me understand where the MEJB is running? The local server or the remote servers? The MEJB connections are done on the remote servers (those that are being monitored with the collecting agent). The collecting agent authenticates itself by having the client pass in the credentials. Then this collecting agent acts as the thin layer between the client and the MEJB, with additional functionality. --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Eric, For this discussion I will use MC for monitoring console (aka client), and agent for mrc-server. It is possible to use 3 G instances (I used this method until GERONIMO-3660). G1 with MC on remote or local m/c, G2 with agent on local m/c, and G3 the instance to be monitored. This is the ideal solution but will be most difficult to implement efficiently. The advantage is that the instance to be monitored is not corrupted in any way. The second option is to use 2 G instances. G1 with MC on remote or local m/c, G2 the instance to be monitored. The agent is loaded in G2. This is what we have now. we need to reduce DB activity. We can improve upon this as we go. The TimeSatistics has 4 values named count, max, min and totaltime. The graph treats count as the current value of time. This is because the information that it is a TimeStatistics is lost in the DB. All four values appear as separate statistics, and the graph would draw each one separately as value, min, max! The same is true for BoundedRangeStatistics. A single graph should show all 5 values. More inline.. The current implementation only allows for one statistic to be shown at a time on a graph, but if you wanted to have the max or min statistics that could be easily obtained since those numbers are there. I think allowing the admin to graph all 4 values on the same graph is a very useful feature and should definitely be added; However, this is not necessarily a stop ship issue. --- Erik B. Craig [EMAIL PROTECTED] wrote: Anita, You mentioned that the collecting agent running within the same jvm (I.E. under a Geronimo instance being monitored as a plugin) is an issue due to resource consumption... however I am unsure what a good alternative approach would be? Are you suggesting we have a separate instance of G to monitor a target instance? Or are you suggesting that the mrc-server be a standalone java app that runs in it's own JVM? This is a possibility too.. Currently the graph builder will plot any data being grabbed as snapshots in any method defined by the user. In the current graph creation page, the user has the option to differentiate between raw count vs. count/time or even count/some other count. There are a lot of options configurable by the user. When I added ErrorCount and ErrorCount/sec graphs to a single view, The other views got corrupted. This is a minor issue and can be easily fixed. Thanks Anita Additionally... do you have an example of the graphs for TimeStatistics or BoundedRangeStatistics being wrong/how they are wrong? Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
