Rescheduling timer is going crazy
See original GitHub issueGreetings, Ralf!
I use Nougat device to test exact job (i need just alarm manager fashioned behavior)
The problem occurs when i return Job.Result.RESCHEDULE
in my onRunJob()
. Looks like the lib trying to reschedule the failed job with startMs
+backoffMs
(which is backoffMs * mNumFailures
in fact) delay. So for example if i schedule the task on +5 hours, the next rescheduled task will trigger in 10 hours + some backoff millis. Which is wrong in my opinion. The rescheduling time should be something like currentTime + currentBackoffMs
I suppose the reason is this piece from com.evernote.android.job.JobProxy.Common#getStartMs:
public static long getStartMs(JobRequest request) {
return checkedAdd(request.getStartMs(), request.getBackoffOffset());
}
Will appreciate any advices.
Issue Analytics
- State:
- Created 7 years ago
- Comments:5
Top Results From Across the Web
Rescheduling a Timer Task (Java in General ... - CodeRanch
No. You have to cancel and then reschedule it. I was asking about canceling a running job, i.e. interrupting its execution, which would...
Read more >TimerTask runs one more time after I call timer.cancel() method
The cancel method will stop all following executions, but not the current one. It your method execution takes a long time, ...
Read more >Timer DSL rule reschedule if state - openHAB Community
Hi, I'm using the DSL rule of this tutorial: Design Pattern: Motion Sensor Timer The problem I'm facing is that sometimes, there is...
Read more >Windows Timer Resolution: The Great Rule Change
Here's the crazy thing: timeBeginPeriod can be called by any program and it changes the timer interrupt interval, and the timer interrupt is ......
Read more >window.setTimeout() goes crazy periodically - Bugzilla@Mozilla
setTimeout() goes crazy periodically - functions are immediately called ... testcase showing timer get called too quickly ... Reschedule the OS timer.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
The behavior has slightly changed. Previously when a job was rescheduled the start and end window increased by the corresponding back-off criteria.
Imagine this job:
When this job was rescheduled for the first time, then the execution window changed to (8_000, 9_000), 2nd fail (13_000, 14_000), …
Now it has changed in that way, that the start and end window aren’t added to the back-off criteria anymore. First fail (5_000, 5_000), 2nd fail (10_000, 10_000), …
Is this helpful?
Fixed in version
1.1.5
. Thanks!