Re: CounterMonitors with offset and modulus

 > Jeremy Boynes wrote:
 >
 > Can someone please clarify the operation of CounterMonitors for me when
 > they have offset, threshold and modulus?
 >
 > I have a counter with an initThreshold of 1, an offset of 1 and a
 > modulus of 5, running in counter mode (not differencing). Over time it
 > has reached a state where the current value is 4 and the threshhold has
 > bumped to 5.
 >
 > If I then set the observed attribute to the value 5, a notification is
 > generated (cool) and in JDK1.5 the threshold is raised to 6. If I then
 > set it to 6, I get another value and the threshold is raised to 7.

The observed attribute can never take 6 as its value because you are
saying with the modulus that the observed attribute goes from 0 to 5
and then rolls over to 0 again.

The CounterMonitor monitors the observed attribute with the behavior
you defined for it. The monitor will only work properly if the counter
behaves as expected. The JMX specification does not define what happens
if you don't respect the rules.

 > How can the value of the threshold be greater than the modulus? I would
 > have expected it to be reset to the initial value 1 (which is what MX4J
 > does) as the spec says "The threshold will then also “roll over”
 > whenever it strictly exceeds the modulus value."

The behavior of the RI is that the threshold is updated, i.e. it rolls
over, when the observed attribute rolls over, i.e. when it is set to 0
again. That's why at a given time you see 6 as the threshold value but
in fact it is reinitialized to the InitThreshold as soon as the observed
attribute rolls over and then it notifies properly.

I think that you are right and that this is a bug in the RI. I would also
like to see the correct threshold value when you query for it. I'll check
with Eamonn to see what he thinks about this issue.

 > Are we meant to detect counter "roll-over" by looking for a decrease in
 > value and only apply the modulus then (although I couldn't see anyhting
 > about that in the spec)?

This is the way the RI is currently implemented and of course the spec
does not say anything about the implementation.

Regards,
Luis


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click