Hangfire: Cómo omitir ejecuciones simultáneas sin fallar en el trabajo
Tengo un trabajo minuciosamente recurrente que usa DisableConcurrentExecution(timeout:0) (0 reintentos), ya que solo un trabajador debería procesarlo en un momento dado, especialmente si el trabajo tarda más de un minuto en completarse (varía).
No quiero que los trabajos "omitidos" se marquen como failed en el panel, así que quería agregar un SkipConcurrentExecutionAttribute que sería casi idéntico a DisableConcurrentExecutionAttribute , excepto que intentaría solucionar la adquisición de la cerradura, tragaría DistributedLockTimeoutException y establecería el trabajo en DeletedState con el motivo.
Pero no puedo hacer esto correctamente, porque GetResource () es privado y su implementación se refiere a otros métodos que son internos a la biblioteca.
$"{job.Type.ToGenericTypeString()}.{job.Method.Name}" parece ser la forma segura de producir nombres de bloqueo distribuidos no conflictivos, pero no puedo referirme a él.
¿Podemos tener en la biblioteca un método público que genere el nombre de bloqueo distribuido del trabajo?
cf., https://discuss.hangfire.io/t/disableconcurentexecution-for-job-groups/1389/4
dgaspar
Todos 4 comentarios
Acabo de notar que filterContext.BackgroundJob.Job.ToString() daría la misma cadena que las implementaciones internas TypeExtensions.cs y DisableConcurrentExecutionAttribute.cs (re) ... problema resuelto.
dgaspar
en 11 jul. 2017
@dgaspar , puede decirle al programador de trabajos recurrentes que omita la creación del siguiente trabajo recurrente, cuando el anterior aún se esté ejecutando, consulte esta esencia: https://gist.github.com/odinserj/a6ad7ba6686076c9b9b2e03fcf6bf74e.
odinserj
en 11 jul. 2017
Gracias por la sugerencia @odinserj. Me di cuenta de que si el trabajador se bloquea durante la ejecución, esa fila "En ejecución" permanecerá en la tabla Hash. ¿Evitará que el trabajo se vuelva a programar hasta que elimine manualmente esa fila? ¿O hay una caducidad / limpieza que me falta? (por cierto, estoy usando new SqlServerStorageOptions { SlidingInvisibilityTimeout = TimeSpan.FromMinutes(5) } , si eso importa)
dgaspar
en 11 jul. 2017
Cuando un trabajador es despedido durante la ejecución de un trabajo en segundo plano, ese trabajo en segundo plano se reprogramará automáticamente, porque todas las colas de mensajes son transaccionales (al menos las oficiales, otras implementaciones de almacenamiento deberían actuar de la misma manera).
odinserj
en 11 jul. 2017
Temas relacionados
dealproc
·
3Comentarios
tompazourek
·
3Comentarios
shorbachuk
·
4Comentarios
cottsak
·
3Comentarios
fb5000
·
3Comentarios
Comentario más útil
@dgaspar , puede decirle al programador de trabajos recurrentes que omita la creación del siguiente trabajo recurrente, cuando el anterior aún se esté ejecutando, consulte esta esencia: https://gist.github.com/odinserj/a6ad7ba6686076c9b9b2e03fcf6bf74e.