geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Date Thu, 06 Dec 2007 17:45:21 GMT

On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote:

>
> --- Viet Nguyen <vhnguy2@gmail.com> wrote:
>
>> On Dec 5, 2007 11:36 PM, Anita Kulshreshtha <a_kulshre@yahoo.com>
>> 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


Mime
View raw message