Let's say the statistic is processingtime (average request processing
time = total time/count) for a web app. Before we hit the web page
for a request, there are no measurements/samples taken. (no probes fired)
If we do a asadmin get to retrieve the stats at this point, it will
return the stats at some initial value. In v2 this initial value for
lastsampletime = current time. In v3 we were thinking -1. This way
there is no doubt that nothing has been collected yet for this stat.
Every time we hit the web page, a measurement is taken for that
processingtime statistic. The count gets incremented, totaltime is
accumulated, and the lastsampletime is set to current time.
After 10 hits, the lastsampletime is the time of the 10th hit (time of
last measurment), and starttime is the time of the 1st hit (time of
first measurement).
That was the thinking behind the logic.
I don't think it was intended for lastsampletime to be the time in which
you run the get command.
Jennifer
Bill Shannon wrote:
> Sankar Neelakandan wrote:
>>
>>
>> Bill Shannon wrote:
>>> So the get command itself doesn't cause a sample to be taken?
>> It does sample the values when the get command is run.
>> For example when a webapp is deployed and the servlet in the webapp
>> is never accessed its requestcount stat will be 0 as initialized by
>> the webcontainer when monitoring is enabled.
>> So you execute the get command , the command goes and "actually"
>> reads/samples the stats value as 0 and compares its value against the
>> initial value (again 0). Since it was never changed the
>> lastsampletime is printed as -1
>
> No change doesn't mean no sample.
>
>> My point is that when a sample is taken whether it is the initial
>> value or changed value, the lastsampletime should be the time when
>> get command is run.
>
> That sounds right to me.
>
> Jennifer, tell us again why you thought it should be changed?