5 ms·

HangFire – Reliable and transparent background job processing for ASP.NET

31 points by odinserj 12y ago

polskibus 12y ago
I wonder how does it compare to Quartz.NET in terms of functionalities, reliability and scalability ? Has anyone used hangfire in production?
- odinserj 12y ago
  Quartz.NET is built around a scheduler, HangFire is built on top of message queues. If you want to off-load a task from the request processing pipeline, message queue is more preferable solution, because it can greatly reduce the latency of background job processing.
jamra 12y ago
How is this any different than using MSMQ?
- rcarmo 12y ago
  Well, it looks like it might run inside Mono, for one.
  - jamra 12y ago
    So something like RabbitMQ would do exactly the same.
  - odinserj 12y ago
    I didn't try to do so, but there is nothing to prevent HangFire to run on Mono. I also consider to support OWIN instead of System.Web for HangFire Dashboard, so Linux and MacOS will be supported.
- mattmanser 12y ago
  MSMQ is a colossal PITA to set up. As is RabbitMQ, etc. I've wanted something like this for a very long time.
- odinserj 12y ago
  HangFire provides you a unified programming model for background job processing on shared, dedicated and cloud hosting. It takes the complexity of background processing itself and lets you to concentrate only on background jobs.
russ519 12y ago
This post could not have come at a better time! I literally spent the better part of yesterday researching best practices for queueing jobs from ASP.NET (WEB API) hosted on Windows Server, not Azure. I was considering NetMSMQ based WCF, Windows Service Bus 1.1, NServiceBus, MassTransit, ServiceStack, Windows Azure Pack, Redis or RabbitMQ hosting Worker Processes as Windows Services. I had settled on the later as I wanted to avoid the complicated configuration of WCF, if possible, and just wanted a simple, reliable, and scalable way, to queue messages and process them. Ideally, I wanted a way to host/launch the worker processes from the web app to avoid complicating the development environment by having to install and run separate processes (Windows Service). I will definitely be looking at this project today and putting it through a PoC. Update: Forgot to mention ServiceStack in list of frameworks considered.
- anton_gogolev 12y ago
  You will inevitably end up with a separate Windows service, mainly for maintanability reasons.
  - russ519 12y ago
    I would love it if you would elaborate on this thought. Are you referring specifically to a solution build with Hangfire or any solution involving worker processes on Windows?
  - odinserj 12y ago
    Why?
hokkos 12y ago
I don't understand why polskibus comment is dead, has I had the same question. I wonder how does it compare to Quartz.NET ?

31 points by odinserj 12y ago

I wonder how does it compare to Quartz.NET in terms of functionalities, reliability and scalability ? Has anyone used hangfire in production?

odinserj 12y ago
Quartz.NET is built around a scheduler, HangFire is built on top of message queues. If you want to off-load a task from the request processing pipeline, message queue is more preferable solution, because it can greatly reduce the latency of background job processing.

jamra 12y ago

How is this any different than using MSMQ?

rcarmo 12y ago
Well, it looks like it might run inside Mono, for one.
- jamra 12y ago
  So something like RabbitMQ would do exactly the same.
- odinserj 12y ago
  I didn't try to do so, but there is nothing to prevent HangFire to run on Mono. I also consider to support OWIN instead of System.Web for HangFire Dashboard, so Linux and MacOS will be supported.
mattmanser 12y ago
MSMQ is a colossal PITA to set up. As is RabbitMQ, etc. I've wanted something like this for a very long time.
odinserj 12y ago
HangFire provides you a unified programming model for background job processing on shared, dedicated and cloud hosting. It takes the complexity of background processing itself and lets you to concentrate only on background jobs.

russ519 12y ago

This post could not have come at a better time! I literally spent the better part of yesterday researching best practices for queueing jobs from ASP.NET (WEB API) hosted on Windows Server, not Azure. I was considering NetMSMQ based WCF, Windows Service Bus 1.1, NServiceBus, MassTransit, ServiceStack, Windows Azure Pack, Redis or RabbitMQ hosting Worker Processes as Windows Services. I had settled on the later as I wanted to avoid the complicated configuration of WCF, if possible, and just wanted a simple, reliable, and scalable way, to queue messages and process them. Ideally, I wanted a way to host/launch the worker processes from the web app to avoid complicating the development environment by having to install and run separate processes (Windows Service). I will definitely be looking at this project today and putting it through a PoC. Update: Forgot to mention ServiceStack in list of frameworks considered.

anton_gogolev 12y ago
You will inevitably end up with a separate Windows service, mainly for maintanability reasons.
- russ519 12y ago
  I would love it if you would elaborate on this thought. Are you referring specifically to a solution build with Hangfire or any solution involving worker processes on Windows?
- odinserj 12y ago
  Why?

hokkos 12y ago

I don't understand why polskibus comment is dead, has I had the same question. I wonder how does it compare to Quartz.NET ?