Hello, @superlogical, thanks for you interest!
But before I start to answer the questions, let me tell you about the differences between Quartz.NET and HangFire. You already know that Quartz.NET is built around scheduler and its main purpose to handle recurring tasks.
HangFire is built entirely for fire-and-forget tasks, and leverages message queues to handle them (but they are persistent comparing to CLR ThreadPool). You can have thousands of messages (queued background work items), and a couple of workers on one or several machines that fetch and process background jobs. So, it is incorrect to talk about worker pool starvation from the queue size point of view – this is the way how HangFire works, message by message, job by job.
- HangFire has the same attribute, but with different name –
DisableConcurrentExecution, you can apply it to the calling method. But be aware of worker pool contention, when all workers waits for the job’s completion. In this case you should start the separate HangFire Server instance with different name for these jobs.
- Recurring job scheduler neither perform the work itself, nor tell a concrete worker to perform it. It only creates a new background job and places it on a queue, and worker thread will fetch it sooner or later (depending on queue size). If the overall latency is very high to you, you can use additional HangFire Server instances. If you want some of your jobs to be performed sooner than the others, consider using multiple queues – you can tell HangFire Server instance what queues it should process.
I’m writing the user guide at the moment, so feel free to ask the questions!
