que sugeriría una mayor flexibilidad y capacidad de configuración a una mejor tienda en su base de datos dos compensaciones: la repeatOffset que le dirá después de cuánto tiempo el trabajo debe ser juzgado y el trialPeriodOffset que mantendrá la información de la ventana de tiempo en que el trabajo es permitido reprogramarse. A continuación, puede recuperar estos dos parámetros como (supongo que está utilizando la primavera):
String repeatOffset = yourDBUtilsDao.getConfigParameter(..);
String trialPeriodOffset = yourDBUtilsDao.getConfigParameter(..);
Entonces, en lugar de la tarea de recordar el contador tendrá que recordar la initalAttempt:
Long initialAttempt = null;
initialAttempt = (Long) existingJobDetail.getJobDataMap().get("firstAttempt");
y realizar el algo como lo siguiente comprobación:
long allowedThreshold = initialAttempt + Long.parseLong(trialPeriodOffset);
if (System.currentTimeMillis() > allowedThreshold) {
//We've tried enough, time to give up
log.warn("The job is not going to be rescheduled since it has reached its trial period threshold");
sched.deleteJob(jobName, jobGroup);
return YourResultEnumHere.HAS_REACHED_THE_RESCHEDULING_LIMIT;
}
sería una buena idea para crear una enumeración para el resultado del intento que se devuelve de nuevo al flujo de trabajo de su núcleo aplicación como la anterior.
luego construir el tiempo de reprogramación:
Date startTime = null;
startTime = new Date(System.currentTimeMillis() + Long.parseLong(repeatOffset));
String triggerName = "Trigger_" + jobName;
String triggerGroup = "Trigger_" + jobGroup;
Trigger retrievedTrigger = sched.getTrigger(triggerName, triggerGroup);
if (!(retrievedTrigger instanceof SimpleTrigger)) {
log.error("While rescheduling the Quartz Job retrieved was not of SimpleTrigger type as expected");
return YourResultEnumHere.ERROR;
}
((SimpleTrigger) retrievedTrigger).setStartTime(startTime);
sched.rescheduleJob(triggerName, triggerGroup, retrievedTrigger);
return YourResultEnumHere.RESCHEDULED;
Gracias. Esto es lo que estaba buscando. – Averroes
-1, no recomiendo este enfoque: bloqueará uno de los hilos de trabajo de Quartz durante 10 minutos.El camino correcto sería facilitar la funcionalidad existente de Quartz, decirle de alguna manera que vuelva a ejecutar el mismo trabajo después de 10 minutos, después de todo, esto es para lo que está hecho. Si vamos a ejecutar algún código y dormir, no tiene sentido usar Quartz en primer lugar. –
complemento que en Quartz 2.0 (para .net al menos). StatefulJob se reemplaza por 'PersistJobDataAfterExecutionAttribute' http://quartznet.sourceforge.net/apidoc/2.0/html/html/babe3560-218c-38de-031a-7fe1fdd569d2.htm – ossek