[OAK-2635] TimeSeriesMax's frequent 'drops to 0'

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.0.12
• Fix Version/s: 1.3.8, 1.4
• Component/s: core
• Labels: observation tooling
• Assignee: Michael Dürig
• Reporter: Stefan Egli
• Created: 16/Mar/15 14:53
• Updated: 26/Sep/19 11:43
• Resolved: 06/Oct/15 09:42

Description

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?

Issue Links

• is blocked by: OAK-3448 Update jackrabbit version to 2.11.1
• is blocked by: JCR-3860 Properly expose missing values in TimeSeries implementations