Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hangfire.io

Post reply on HN
Print view View original

11–14 of 14 posts

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

#11

Post by odinserj »

rcarmo wrote: post #4
jamra wrote: post #3

How is this any different than using MSMQ?

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

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.

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

#13

Post by odinserj »

polskibus wrote: post #2

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

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.

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

#14

Post by odinserj »

anton_gogolev wrote: post #6
russ519 wrote: post #5

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 wa…

You will inevitably end up with a separate Windows service, mainly for maintanability reasons.

Why?
Post reply on HN