Scheduler.schedulePeriodically is sensitive to system time changes

[psliwowski]

Scheduler.schedulePeriodically can potentially get into busy loop if you set your system time into the future due to using System.currentTimeMillis() to calculate the next delay.

[psliwowski]

Confirmed this causes a busy loop and spikes cpu to 100% because of ObjectPool.

[akarnokd]

I guess it is due to the way the next delay is calculated from a constant absolute time position and a time set back will result in 0 delay between subsequent executions. Any tips on fixing it?

[zsxwing]

If we want to measure elapsed time, we should use System.nanoTime, which won't be affected by the user's system time. https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()

[akarnokd]

I wouldn't trust nanoTime that much because the weaker guarantees of its monotonity and consistency across cores.

[headinthebox]

This is not an easy thing ;-) http://blogs.msdn.com/b/rxteam/archive/2012/06/20/reactive-extensions-v2-0-release-candidate-available-now.aspx

[akarnokd]

@headinthebox Especially if you are platform independent to begin with (i.e., what is the Linux equivalent of SERVICE_CONTROL_TIMECHANGE callback?)

What the solution boils down:

1. We need a supervising task scheduled on a small, 5-10s period to detect System.currentTimeMillis() drift or change (i.e., now - last is: > 5s + tolerance / negative).
2. We need to capture tasks scheduled on any Scheduler that sets a delay/period > 10s and schedule them according to Zeno's paradox.
3. If the supervising task detects a drastic clock change, it has to catch all those long-delay tasks and re-schedule them based on the new absolute time information, of course, atomically to prevent double-executions.

These all add some non-trivial overhead to scheduling and task-memory-sizes.

My first thought was the same as in the article:

Observable.Timer/Interval implementation would start its quest to catch up with the new time, draining the battery due to the flood of callbacks it triggered. The fix was more of a band aid, whereby the timer would ignore ticks that occurred in the distant past, resetting the “next” state to be based on the current system time.

But that's still a half-solution at best.

[psliwowski]

Using nanoTime was my temporary solution as well. It is not the best, but the quickest way to fix this bug and doesn't offer anything worst then the current solution.

[artem-zinnatullin]

Some systems like Android give a way to measure time and don't care about system time changes. http://developer.android.com/reference/android/os/SystemClock.html

What do you think about abstraction for System.currentTimeMillis() which can be overridden via RxJava Plugin?

Default: System.currentTimeMillis() -> no breaking changes to the API.
Android: SystemClock.elapsedRealtime() -> no breaking changes and guarantees++ for free.
Others: users can provide custom implementation, for example for Linux it can be native C call, or in general it can be some implementation of synchronized calls to System.nanoTime().

[akarnokd]

I've implemented compensation logic in 2.x but I haven't tested it and unsure if the calculation is actually correct.

[akarnokd]

I've proposed a fix for this issue in #3467. I don't know if and when this can get into a release.