Job Rehydration
By default, the persistent scheduler module will attempt to rehydrate jobs according to the statuses described here
In some circumstances you might want to delay this rehydration until you have performed some processing downstream. For example, if you want to cancel some recurring jobs stored in the database and reload them from the latest configuration. You might want these two tasks to complete prior to rehydration of jobs to avoid any processing conflicts.
In this case you can update the following property:
ipf.persistent.scheduler.automatically-rehydrate-jobs to false. This will cause rehydration of jobs from the database back into the scheduler to only occur upon receipt of a RehydrateAndStopCommand message by the JobRehydratorActor.
Setting the above property allows downstream projects control over the timing of Job Rehydration.
Job Rehydration is a one time application startup activity. As such the JobRehydratorActor will shut-down after processing a RehydrateAndStopCommand.
|
Commands to the JobRehydratorActor can be sent using AskWithRetry. The following properties configure the retries of commands sent to this actor:
| Property | Default |
|---|---|
|
2s |
|
2 |
|
0.2 |
|
5 |
You can wire in the SchedulerRehydrationRetryProperties class to leverage the above configuration and AskWithRetry pattern for example:
@RequiredArgsConstructor
public class FilePollerScheduler {
private final SchedulerRehydrationRetryProperties schedulerRehydrationRetryProperties;
public CompletionStage<Void> scheduleFilePollingJobs() {
// ... additional logic to perform before rehydration
AskWithRetry<SchedulingCommand, Done> askWithRetry = schedulerRehydrationRetryProperties.newRetryBuilder()
.ref(processRehydratedJobsSchedulerSingleton)
.msgFactory(JobRehydratorActor.DoProcessRehydrateJobsCommand::new)
.build();
return askWithRetry.start()
.thenAccept(__ -> log.debug("Rehydrate called after custom logic"));
}