Dynamic Recurring Task Scheduling Delayed Due to Fixed Delay from Execution Completion and Polling Interval.

[RohitBhalekar-dev]

Use Case:

I am working on implementing a system that needs to schedule recurring tasks with flexible intervals (e.g., every hour, every day). The task should start at a specific point in time (i.e., an Instant), and from that start point, it should execute at regular intervals.

For example, I want to print a message like "Hi! Welcome to DB Scheduler" every hour, starting at midnight, two days from now.

Current Approach:

Currently, I am using a Dynamic Recurring Task approach where I specify a data for the task, and I use a fixed delay for scheduling, along with an initial start time (the initialDateTime) which defines when the recurring task should begin.

Here’s the code I am using to schedule the task:

Schedule schedule = Schedules.fixedDelay(Duration.of(1, ChronoUnit.HOURS));
SchedulableInstance<ScheduleAndData> scheduleInstance = 
    SchedulableInstance.of(notificationDynamicRecurring.instance(id, 
        ScheduleAndData.of(schedule, data)), initialDateTime);
scheduler.schedule(scheduleInstance);

In this code:

initialDateTime = 10/02/2025T00:00:00.000Z (the time when the task should first run)
pollingInterval = 1 second (how often the scheduler checks for task execution)
This should result in the task being executed every hour, starting exactly at the specified initialDateTime.

Expected Output:

The expected behavior is that the first execution should happen at initialDateTime, and subsequent executions should occur every hour from that point onward. So, based on the example above, the task should execute as follows:

1st Execution: 10/02/2025T00:00:00.000Z
2nd Execution: 10/02/2025T01:00:00.000Z
3rd Execution: 10/02/2025T02:00:00.000Z
This assumes that the fixed delay (1 hour) is being calculated relative to the initialDateTime, and there should be no delays or accumulation between executions.

Actual Output:

However, the actual behavior is different. The task does not execute at the expected times. Instead, the task is scheduled after the completion of the current execution, leading to a cumulative delay. As a result, the actual task executions are happening at the following times:

1st Execution: 10/02/2025T00:00:01.000Z (1 second after the expected time)
2nd Execution: 10/02/2025T01:00:02.000Z (2 second after the expected time)
3rd Execution: 10/02/2025T02:00:03.000Z (3 second after the expected time)

As you can see, each execution is delayed by 1 second, and this delay accumulates for every subsequent execution.

Possible Issue:

1. Cumulative Delay and FixedDelay Calculation:
The root cause of this behavior seems to be that the next execution is scheduled based on the completion of the current task, rather than based on the original initialDateTime and the fixed delay (FixedDelay). In other words, the scheduler is adding the delay after the completion time of each task, instead of from the start time (initialDateTime).

Since the tasks are executed with an incremental delay between each execution, the delay between them grows over time, which is not the intended behavior.

The expected behavior is that the next task should be scheduled at the time calculated as initialDateTime + FixedDelay (i.e., starting from the defined initialDateTime and maintaining the fixed delay between tasks). This ensures there is no accumulation of delays or shifts in the execution times.

2. Impact of Increasing Polling Interval:
Additionally, I noticed that increasing the polling interval from 1 second to 10 seconds results in a similar effect, where the time difference between executions increases. This is because the longer polling interval consumes additional time (i.e., heartbeat time), further extending the delay between executions.

For example, if the polling interval is set to 10 seconds, the time between each execution becomes longer as the scheduler spends time processing the heartbeat. This further amplifies the issue and causes a larger discrepancy between the expected and actual execution times.

In this scenario, the increase in the polling interval leads to more significant delays, compounding the problem.

3. Impact of Decrease in Polling Interval
Additional, Decrease in polling interval would result in more request to the db which is not prefered.

Request for Help/Clarification:

Is this behavior intentional in the current scheduling implementation, where the next execution is scheduled relative to the completion of the current execution?

If this is the expected behavior, is there any way to modify the scheduling logic so that the next execution time is always calculated from the original initialDateTime + the fixed delay (without considering the completion time of the previous task)?

Alternatively, is there a known workaround or configuration option that can be used to ensure that the task runs strictly on a recurring schedule based on the initialDateTime and fixed interval, without the incremental delay caused by task execution times?

I appreciate any guidance or suggestions on how to address this issue!