TimerTask should schedule next run before doing job

[divanikus]

As far as I understand the logic behind the TimerTask, it should run a job every execution seconds and kill it if it running too long.
The current logic is a little bit different. It causes a job to be run execution seconds after it did the previous iteration.
Short example. If I need to poll something every 30 seconds. I'll create a timer task with execution_interval set to 30 and say timeout set to 15 seconds. My code is polling a slow thing which can reply in 20 seconds or more.
What I expect:

0:00 Poll
0:10 Poll finished
0:30 Poll
0:45 Poll finished
1:00 Poll
1:05 Poll finished
1:30 Poll
1:35 Poll finished
...

What really happens with TimerTask:

0:00 Poll
0:10 Poll finished
0:40 Poll
0:55 Poll finished
1:25 Poll
1:30 Poll finished
2:00 Poll
2:05 Poll finished
...

Now TimerTask doesn't look like a good candidate for polling.

#!/usr/bin/env ruby
require "concurrent"

puts "Creating tasks"
10.times do |x|
  task = Concurrent::TimerTask.new(run_now: true, execution_interval: 20) do
    sleep x*2
    puts "#{Time.now} #{x*2} finished"
  end
  task.execute
end

sleep 60
puts "Terminated"

The output:

Creating tasks
2017-10-19 01:41:48 +0300 0 finished
2017-10-19 01:41:50 +0300 2 finished
2017-10-19 01:41:52 +0300 4 finished
2017-10-19 01:41:54 +0300 6 finished
2017-10-19 01:41:56 +0300 8 finished
2017-10-19 01:41:58 +0300 10 finished
2017-10-19 01:42:00 +0300 12 finished
2017-10-19 01:42:02 +0300 14 finished
2017-10-19 01:42:04 +0300 16 finished
2017-10-19 01:42:06 +0300 18 finished
2017-10-19 01:42:08 +0300 0 finished
2017-10-19 01:42:12 +0300 2 finished
2017-10-19 01:42:16 +0300 4 finished
2017-10-19 01:42:20 +0300 6 finished
2017-10-19 01:42:24 +0300 8 finished
2017-10-19 01:42:28 +0300 0 finished
2017-10-19 01:42:28 +0300 10 finished
2017-10-19 01:42:32 +0300 12 finished
2017-10-19 01:42:34 +0300 2 finished
2017-10-19 01:42:36 +0300 14 finished
2017-10-19 01:42:40 +0300 4 finished
2017-10-19 01:42:40 +0300 16 finished
2017-10-19 01:42:44 +0300 18 finished
2017-10-19 01:42:46 +0300 6 finished
2017-10-19 01:42:48 +0300 0 finished
Terminated

Consider the increasing intervals.

---

• Operating system: linux
• concurrent-ruby version: 1.0.5
• concurrent-ruby-ext installed: no
• concurrent-ruby-edge used: no

[pitr-ch]

Thanks, I'll have look if we could add an option for the behavior you want.

[Yax]

Maybe you know any workarounds for this problem?

[bensheldon]

I looked into implementing this. There's two new strategies here, and I'm not sure if both of them should be implemented or just one is what's necessary.

The simplest strategy is to do this, which will simply calculate the interval dynamically based on the runtime of the previous task:

next_interval = (interval - last_runtime).clamp(0, Float::INFINITY)

But, if the last_runtime value is greater than the interval, what should happen?

• The next task could run immediately after the previous task completes, but that still means that the tasks could run at a longer interval than configured.
• The next task (or any number of subsequent tasks) could run concurrently with the previous task(s). This would maintain the interval, but could fill up the thread-pool executor (which isn't currently configurable, though that would be nice).

The simpler strategy is easier to implement, but does not maintain the interval. The more complicated strategy would require removing at least one mutex (there is more synchronization in the TimerTask than I expected and I'm not sure why it so defensive).

What are people's needs? Would the simpler strategy suffice or does there need to be multiple options? e.g. interval_strategy:

• :between: (current) interval is calculated after task completes
• :serially: interval is maintained if the task duration is less than the interval, otherwise the next task run immediately and serially.
• :concurrently: interval is maintained if the task duration is less than the interval, otherwise the next task begins after the interval and concurrently with other previous tasks

Naming suggestions are very welcome.

[bensheldon]

I drew a picture of the different strategies.

I could also imagine this is two different arguments:

• interval_from: :start/:finish
• concurrent: true/false

[eregon]

I think we'd want two strategies, the same as Java's Timer: https://docs.oracle.com/javase/8/docs/api/java/util/Timer.html (fixed-delay execution vs fixed-rate execution), because I think there are use cases for both.

[eregon]

And I think concurrent is too dangerous (easy to have too many concurrent tasks and end up in DoS) and unexpected, so unless we have a real use-case for that I wouldn't add it.
Maybe there should be a way to cancel the current task if it takes too long, but cancelling is typically dangerous too. Ultimately one needs to fix the task so it doesn't take too long for most runs anyway.

[bensheldon]

Thank you @eregon for that direction! I've opened up a PR: #997