
HangFire – Reliable and transparent background job processing for ASP.NET - odinserj
http://hangfire.io
======
russ519
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
You will inevitably end up with a separate Windows service, mainly for
maintanability reasons.

~~~
russ519
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?

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

~~~
odinserj
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.

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

------
jamra
How is this any different than using MSMQ?

~~~
rcarmo
Well, it looks like it might run inside Mono, for one.

~~~
odinserj
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.

