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
