Failed Jobs
Un trabajo fallido se define como un trabajo que cumple con los siguientes criterios:
-
Ha perdido su ventana de ejecución regular sin cambios en su especificación, O;
-
Fue programado para estar en el pasado (fuera de la past acceptance window)
-
Su especificación fue actualizada de una manera que detiene cualquier ejecución futura
The Failed Jobs Processor
Cuando el sistema se inicia, programa un trabajo interno para encontrar cualquier trabajo programado que haya fallado. Este trabajo se comporta como cualquier otro trabajo programado. Tiene la tarea especial de identificar otros trabajos que han fallado, según los criterios anteriores, y luego procesarlos (ver detalles abajo).
La frecuencia de ejecución es configurable y puede establecerse usando el siguiente archivo de propiedades:
package com.iconsolutions.ipf.core.platform.scheduler.persistent.job;
import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
@Data
@ConfigurationProperties(prefix = "ipf.persistent.scheduler.process-failed-jobs")
public class ProcessFailedJobsProperties {
private Boolean active;
private String cronExpression;
}-
active: una bandera para indicar si el trabajo está activo o no -
cronExpression: una expresión cron para describir la frecuencia con la que se ejecutará el trabajo. Para ayuda para construir una expresión cron, use un generador de expresiones cron en línea como este.
El siguiente ejemplo lo establece para ejecutarse una vez al día a las 0:15:59:
ipf.persistent.scheduler.process-failed-jobs {
active = true
cron-expression = "59 15 0 */1 ? *"
}Ser notificado de trabajos fallidos
Al configurar un JobSpecification, es posible ser notificado de fallos para ese trabajo específico especificando el identificador y comando de fallo:
JobSpecificationDto.builder()
.jobRequestor(JOB_REQUESTOR)
.triggerCommand(TEST_COMMAND)
.schedulingSpecification(cronExpression)
.failureIdentifier(failureIdentifier) (1)
.failureCommand(failureCommand) (2)
.build();Si este trabajo ha fallado desde el último checkpoint, entonces el SchedulingHelper relevante será notificado de esto. Note que el SchedulingHelper necesitará tener actualizado el método supports para soportar también el comando de fallo.