[
https://issues.apache.org/jira/browse/OAK-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-2635:
-------------------------------
Labels: observation tooling (was: tooling)
> TimeSeriesMax's frequent 'drops to 0'
> -------------------------------------
>
> Key: OAK-2635
> URL: https://issues.apache.org/jira/browse/OAK-2635
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0.12
> Reporter: Stefan Egli
> Assignee: Michael Dürig
> Labels: observation, tooling
> Fix For: 1.3.0
>
>
> The current implementation of TimeSeriesMax - which is what is backing eg the
> very important 'ObservationQueueMaxLength' statistics - has a very infamous
> behavior: it does very frequent, intermittent 'jumps back to 0'. This even
> though the queue-lengths are still at the previous highs, as can often be
> seen with subsequent measurements (which eg are still showing there are 1000
> events in the observation queue).
> The reason seems to be that
> * the value is increased via {{TimeSeriesMax.recordValue()}} during a 1
> second interval
> * reset to 0 via {{TimeSeriesMax<init>.run()}} every second
> So basically, every second the counter is reset, then during 1 second if any
> call to {{recordValue()}} happens, it is increased.
> This in my view is rather unfortunate - as it can result in mentioned
> 'jumpy-0' behavior, but it can also jump to values in between if the largest
> queue does not reports its length during 1 second.
> It sounds a bit like this was done this way intentionally? (perhaps to make
> it as inexpensive as possible) or could this be fixed?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
