Job Rehydration
Por defecto, el módulo persistent scheduler intentará rehidratar trabajos según los estados descritos aquí
En algunas circunstancias podría querer retrasar esta rehidratación hasta que haya realizado algún procesamiento aguas abajo. Por ejemplo, si desea cancelar algunos trabajos recurrentes almacenados en la base de datos y recargarlos desde la configuración más reciente. Podría querer que estas dos tareas se completen antes de la rehidratación de trabajos para evitar conflictos de procesamiento.
En este caso puede actualizar la siguiente propiedad:
ipf.persistent.scheduler.automatically-rehydrate-jobs a false. Esto hará que la rehidratación de trabajos desde la base de datos de vuelta al scheduler solo ocurra al recibir un mensaje RehydrateAndStopCommand por el JobRehydratorActor.
Establecer la propiedad anterior permite a los proyectos aguas abajo controlar el momento de la Job Rehydration.
La Job Rehydration es una actividad única de arranque de la aplicación. Como tal, el JobRehydratorActor se apagará después de procesar un RehydrateAndStopCommand.
|
Los comandos al JobRehydratorActor pueden enviarse usando AskWithRetry. Las siguientes propiedades configuran los reintentos de los comandos enviados a este actor:
| Property | Default |
|---|---|
|
2s |
|
2 |
|
0.2 |
|
5 |
Puede cablear la clase SchedulerRehydrationRetryProperties para aprovechar la configuración anterior y el patrón AskWithRetry, por ejemplo:
@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.RehydrateJobsCommand::new)
.build();
return askWithRetry.start()
.thenAccept(__ -> log.debug("Rehydrate called after custom logic"));
}
}