Solución:
No estoy seguro de cuándo se admitió esto, pero probé esto en ASP.NET Core 2.0 con Hangfire 1.7.0. El siguiente código programa un trabajo cada 20 segundos:
RecurringJob.AddOrUpdate<SomeJob>(
x => x.DoWork(),
"*/20 * * * * *");
Si no me equivoco, se admiten 6 tokens (a diferencia de los 5 tokens estándar) debido al uso de Hangfire de NCrontab, que permite expresiones cron con 6 tokens (granularidad de segundo en lugar de granularidad de minuto).
El panel de Hangfire también muestra muy bien el pequeño intervalo de tiempo entre ejecuciones:
Creo que cualquiera que esté en contra de permitir un disparador recurrente de menos de 1 minuto es miope. Después de todo, ¿55 segundos son menos eficientes que 1 minuto? ¡Parece tan arbitrario! Por mucho que me encanta Hangfire, me he encontrado con situaciones en las que tuve que dirigir a un cliente a Quartz.net simplemente porque había un requisito comercial para que un trabajo se ejecutara cada 55 segundos o algo similar.
Cualquiera que defienda el argumento contrario de que si se configurara para ejecutarse cada 1 segundo tendría un impacto grave en el rendimiento, vuelve a tener una visión cerrada de las cosas. Por supuesto, un disparo con un intervalo de 1 segundo probablemente no sea una buena idea, pero ¿no permitimos 55 segundos o 45 segundos para la situación poco probable en la que alguien elija 1 segundo?
En cualquier caso, el rendimiento es subjetivo y depende de la plataforma y el hardware del host. Realmente no depende de la API hacer cumplir la opinión en lo que respecta al rendimiento. Simplemente configure el intervalo de sondeo y la recurrencia del disparador. De esa manera, el usuario puede determinar el mejor resultado por sí mismo.
Aunque un proceso en segundo plano que orquesta un trabajo para que se ejecute cada 55 segundos puede ser una opción, no es muy satisfactorio. En este caso, el proceso no es visible a través de la interfaz de usuario de Hangfire, por lo que está oculto para el administrador. Creo que este enfoque está eludiendo uno de los principales beneficios de Hangfire.
Si Hangfire fuera un competidor serio de Quartz.net, al menos coincidiría con su funcionalidad básica. Si Quartz puede admitir disparadores con un intervalo inferior a 1 minuto, ¿por qué no puede Hangfire?
Aunque Hangfire no le permite programar tareas por menos de un minuto, puede lograrlo si la función se programa de forma recursiva; es decir, digamos que desea que se active algún método cada 2 segundos. Puede programar un trabajo en segundo plano que llame al método en el inicio;
BackgroundJob.Schedule(() => PublishMessage(), TimeSpan.FromMilliseconds(2000));
Y luego, en su método PublishMessage, haga sus cosas y luego programe un trabajo para llamar al mismo método;
public void PublishMessage()
{
/* do your stuff */
//then schedule a job to exec the same method
BackgroundJob.Schedule(() => PublishMessage(), TimeSpan.FromMilliseconds(2000));
}
La otra cosa que debe anular es el SchedulePollingInterval predeterminado de 15 s; de lo contrario, su método solo se activará después de cada 15 s. Para hacerlo, simplemente pase una instancia de BackgroundJobServerOptions a UseHangfireServer en su inicio, así;
var options = new BackgroundJobServerOptions
{
SchedulePollingInterval = TimeSpan.FromMilliseconds(2000)
};
app.UseHangfireServer(options);
No sé qué tan “infalible” es mi solución, pero logré lograr mi objetivo con ella y todo es “feliz” en producción.