[jira] [Updated] (OAK-2635) TimeSeriesMax's frequent 'drops to 0'

["Michael Marth (JIRA)" <ji...@apache.org>]

     [ 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)