We left Russia. We are against aggression and war with Ukraine. It is a tragedy for our nations, it is a nightmare

Recurring Jobs are not sending a Service Bus Message

I am setting up some recurring tasks to run on queues that are setup to use Azure Service Bus.
When the recurring job is triggered manually (via the dashboard) the job is detected and executed immediately.
But when the job is left to execute at the allotted time, no Service Message is sent and instead a secondary, duplicate queue appears in the dashboard, containing the job - but it remains “Enqueued” indefinitely - as the background server setup to “watch” that queue doesn’t know about, presumably because not Message came down via Service Bus.

My workaround at the moment is to have a dedicated, “recurring” queue, that is not using Service Bus, with each recuring job then triggering an normal Background job on the desired queue. But this creates an extra Job, a delay in execution and a polling load on the database that I was hoping to avoid completely.

To add some further context. I’ve just recreated the problem situation with a clean-slate hangfire db. And surprisingly the first Cron-triggered execution did work as intended, and the corresponding Service Bus Message can be seen. But all subsequent Cron-based executions has resulted in the “duplicate” queue manifesting and no Service Bus message. Behind the scences, I can see rows have been inserted into the JobQueue table. This does not happen on normal background jobs, because this is what Hangfire.Azure.ServiceBusQueue replaces (I think).

Is there something I’m not doing correct in the setup of UseServiceBusQueues? All normal background jobs queue and execute correctly. I tried to follow the difference in code between Triggering and background job immediately and normal Cron based execution, but I could not follow the logic easily.

Thanks in advance.

I’d recommend using just Hangfire.SqlServer without any external queues – they add more problems than solve, and I did my best to avoid any reason of using them – fetching with SQL Server-based queues became better over the years.

It would seem you are right. Further testing of the Service Bus extension showed it was polling the various queues (not pushing as I’d thought/hoped) meaning the network traffic was as much if not more than your revised SQL Server-based implementation.

Thank you for your response.

One thing to note – please ensure you have recommended options turned one to have the best experience. Those options will be enabled by default for “still upcoming” 1.8.0.