[QUESTION] Reschedule without removing initial task

[Writtscher]

Hi. I am trying to find a way to implement a task with max retries. I have checked your examples especially the max retry example but the problem is that in the end the task is stopped (removed). I'd like to avoid this.

So what I'd like to implement:

RecurringTask scheduled (runs every morning at 8 am). If the first run fails the task retries for MAX_RETRIES. If every retry fails go back to default scheduling (next day 8 am. This is pretty easy. The problem is: How do I implement a retry for this run? Because the task error count is at MAX_RETRIES. So I cannot check whether error count < MAX_RETRIES.. I need some kind of run state.

With quartz you would just create for this task another trigger and keep your initial trigger. This trigger retries and removes itself if the task succeeds or fails at MAX_RETRIES..

This is not possible right now. A executionOperations.reset() would be nice.

[Writtscher]

Well I found a way but it is a bit complicated:

I have implemented a FailureHandler with the schedule of the task as a field. So my failure implementation is like this:

If(time of execution is before next execution time and error count < error count + MAX_RETRIES) then reschedule in 5 minutes(for example) else just reschedule with next schedule time.

Works but is kinda cumbersome.

[kagkarlsson]

Hi! Will have a more in-depth look at the code regarding consecutive failures, but one thing that is possible right now is to track the state yourself in task_data, i.e. create some simple Serializable class to persist with the execution.

May get some hints from this example:
https://github.com/kagkarlsson/db-scheduler/blob/master/db-scheduler/src/test/java/com/github/kagkarlsson/scheduler/example/SchedulerMain.java#L46

[kagkarlsson]

(so you would handle it in the `.execute((taskInstance, executionContext) -> {..´ method and not let the exception propagate to the FailureHandler. It would not be tracked as a failure by the scheduler though (if that is important.. )

[kagkarlsson]

But I see your point, a way to "reset" the failure-history would be helpful. So maybe a set of methods on ExecutionOperations that does the same thing as reschedule, but also sets failures to 0 and last failure to never.

public void reset(ExecutionComplete completed, Instant nextExecutionTime) {
    ...
}

[Writtscher]

Yes this would be nice. This way my logic would be much easier.

[Writtscher]

(so you would handle it in the `.execute((taskInstance, executionContext) -> {..´ method and not let the exception propagate to the FailureHandler. It would not be tracked as a failure by the scheduler though (if that is important.. )

I do not think this is a good approach. Failed execution should be treated as failures. No exception means successful run. This is not the right behaviour

[Writtscher]

But I see your point, a way to "reset" the failure-history would be helpful. So maybe a set of methods on ExecutionOperations that does the same thing as reschedule, but also sets failures to 0 and last failure to never.

public void reset(ExecutionComplete completed, Instant nextExecutionTime) {
    ...
}

Is it necessary to set last failure to null? Just setting the error count to zero is enough imo.

[kagkarlsson]

Yes, drafted it now and landed on that aswell

public void rescheduleAndResetFailures(Instant nextExecutionTime) {

contemplating what the name of the method should be 🤔

[Writtscher]

Is it possible to have the Schedule of the task in the ExecutionOperations? Did not dive deep into the code.

If it is possible to have this information then I'd prefer something like

public void rescheduleWithDefaultSchedule()

This resets the error count and sets the next run to the schedule.getNextExecutionTime(executionComplete).

[kagkarlsson]

The Schedule is not accessible that this point because it is a special construct for the recurring tasks.

[kagkarlsson]

Draft PR #119, hopefully I can get it released in a couple of days

[Writtscher]

Looks ok. Maybe also add a default RetryFailureHandler? Like the one of your example?

[kagkarlsson]

This is taking a bit longer than anticipated. Hoping to get some time to finish it soon.

[LeslieMurphy]

Hi! Will have a more in-depth look at the code regarding consecutive failures, but one thing that is possible right now is to track the state yourself in task_data, i.e. create some simple Serializable class to persist with the execution.

May get some hints from this example:
https://github.com/kagkarlsson/db-scheduler/blob/master/db-scheduler/src/test/java/com/github/kagkarlsson/scheduler/example/SchedulerMain.java#L46

File location has moved. Sample code using Integer class as task data is here:

https://github.com/kagkarlsson/db-scheduler/blob/master/examples/features/src/main/java/com/github/kagkarlsson/examples/SchedulerMain.java

CustomTask<Integer> custom1 = Tasks.custom("recurring_changing_data", Integer.class)