RRD4j: This happens when three state updates occur in two seconds. What happens is:
- first state arrived and is persisted with t=1.
- second state arrives 700ms later (t=1.7, truncated to 1): add-on detects the same timestamp and schedules a new attempt in 1s
- third state arrives about 700ms (t=2.4) later and is persisted with t=2
- the scheduled attempt for the second state is executed (t=2.7, 1s after the initial attempt, truncated to 2) and fails again because the third state was already persisted with t=2. Since this was already a second attempt, the warning is printed.
This is a bit more strict than before, where there were unlimited re-tries. I’m not convinced that this is better, because the “original” timestamp and the finally persisted timestamp could be very far apart for fast-changing items.