You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Worker and Dispatcher share the same poll loop logic
(Poller#start_loop) while having different functional requirements.
The Worker is poll looping despite not being able to execute new
jobs if at capacity.
The Dispatcher does require polling, but is reliant on shared
logic in Poller#start_loop for a Dispatcher specific optimization.
Changes:
Move the logic controlling the sleep interval per poll from
Poller#start_loop into Worker#poll and Dispatcher#poll by
requiring #poll to return the `delay` value passed into
interruptible_sleep.
Poller#start_loop:
* Removes the test based on the number of rows processed by #poll. This
was Dispatcher specific logic.
Worker#poll:
* When Worker at full capacity: return a large value (10.minutes)
effectively transforming Poller#start_loop from polling to wake-on-event.
* When Worker < capacity: return `polling_interval` and maintain the poll
timing until ReadyExecutions become available.
Dispatcher#poll:
* When `due` ScheduledExecutions.zero? return `polling_interval` and
maintain the existing poll timing when no ScheduledExecutions
are available to process.
* When `due` ScheduledExecutions.postive? return 0. This results in
interruptible_sleep(0) which returns immediately and without introducing
any delays/sleeps between polls. This also allows for the existing behavior
of looping through ScheduledExecutions via poll in order to check for
shutdown requests between dispatch_next_batch interations.
0 commit comments