Agree.

Quartz FTW!

I love Nick and pretty much watch all his videos but bless him, he does love the clickbait titles and images.

For a small site where you don't need fancy features, Coravel is the easiest one to use by far. I love it.

Nick almost always uses clickbait titles. Often has the opposite effect on me making me not watch his videos lmao.

Perfect comment. Even to do a simple benchmark Hangfire can be a pain due to its heavy static based usage. But after looking into the source code and managing to find its proper instance structures to benchmark I have found that Quartz performs much better. Hangfire also seems to have some kind of internal process that runs from time to time that causes some hanging and delays the scheduled tasks by some seconds (up to 20s)

Hang fire doesn't do well in a containerized environment. The workers stops working at some point and that affects recurring tasks. quartz is better especially in containerized environment.

Quartz is in the middle of a rewrite for nosql and other improvements, though, so support is currently slow or lacking

Totally agree, Hangfire almost the same no updates or major enhancements for many years. Quartz does the job and more.

Also agree, I would never recommend Hangfire over Quartz unless a commercial support contract was mandatory.

To secure it, you need to pass an authorization filter in the options for UseHangfireDashboard.

Curious, what's the async/await problem?

Hi there. Apologies if you already know this, but thought I would offer a suggestion. You can give your jobs a Display Name and incorporate instance arguments into the name. The display name is then displayed as the job name in the dashboard. This doesn't solve the problem of being able to search for a specific job, but you could for example set your paging to 50 or 100 per page, and then use the in browser search. Your code might look something like this: public class MyJobClass { [DisplayName("Job for customer {3} with argument {0} and number {1}")] public async Task MyJobMethod(string argument1, int argument2, string customerName) { .... // Your method code } } This can be helpful for tracking down specific instances of regularly run jobs.

Yes, you need to make sure that your job processing is deterministic

Buy the full version, this can guarantee that jobs do not run more than once even across different deployments

Unfortunately my post was deleted. So can use it this way: private readonly ReaderWriterLockSlim locker = new(); public void MyReccuringTask() { try { locker.EnterWriteLock(); // Do your stuff } finally { locker.ExitWriteLock(); } }

Have you tried increasing invisibility timeout/sliding invis timeout? It's 30 min by default iirc so any job that takes longer than that will start over

no, i am

@@jacobmars1902 No, IM Nick, and so's my wife

I’m Nick and so is my wife!

It says in your Username you are Philip tho

@@BetrayedEnemy I'm Nick

i agree, while i understand that hangfire is from a time looong before ServiceCollection or other "modern" patterns (like a non-static builder pattern) i really wish that hangfire upgrades to a non-static builder. I really see no reason not to. If i want a static IJobScheduler, let me do that, but don't force it on me (have everything available static even if i don't want).

I do personally created some 'system tests' which is pretty much reproducable. (except the part when it is affected by other service - but you might prepare similar thing with more static data). However initial phase of it is to drop and recreate database and start from 'blank environment' -> next step is to create a HangfireServer which is assigned to 'test customer' (each server which we have is responsible of different customers with different databases) - after that I've created a 'WaitForJob' method which works on while loop searching for not finished (failed) jobs and let rest of the process to continue when it is '0'. but indeed - there is a lot of static and is like part of documentantion also in places when you have other options. Dashboard however is a bit annoying, becouse if I want to cover new 'customer database' it have to be re-released becouse route have to be registred

It’s matter of taste in general or what’s in use in company you working at. In fact it’s all json files and ui - forms and buttons, cli or your preferred prog language script.

Insomnia is way better at saving params and collections in a Git friendly form (although not perfect), making usable for sharing across the team. And I think it even has a free feature for sharing, but not sure on that one.

It's running in the server instance. Everything needed to run the command has to have been serialised, and if you are running a custom class you need to make sure that DLL is present and registered on each destination server. Job dispatching is done from outside of the service, so there is no 'call back' occurring. In theory you could insert a record straight into the database from a command prompt, and one of your Hangfire server instances would see it, consume it, run it, then save the result in the job result. Remember that this is not some form of RPC, it is a scheduler, so as far as client apps are concerned it's fire and forget. You have API calls to request the status of jobs by your own criteria, so you might add a GUID to your job data, then poll Hangfire afterwards and ask it if the job with that GUID passed or failed, but it is a scheduler. I use this for large scale ETL processes and client emailers, with custom jobs. I run thousands of jobs per day, and send out hundreds emails, each being its own job. I can check the failed jobs list in the Dashboard for problems, and rerun them manually. It is an extremely powerful system, and the Dashboard makes it more acceptable to clients than Quartz.

As said, it''s run on the server. If you need scalability (and don't want to send a bunch of dlls to another server after each build...), use a webApi endpoint on your main application. It may be slower, but you never will need to touch your Hangfire server. Or messaging. Messaging works too.

@@RaMz00z I'm not sure what you're suggesting here. Creating a webAPI prevents scalability, as it's a single endpoint. Whatever you do for scaling you will have to distribute custom DLLs (unless it's a simple enough function to serialise as in Nick's example which is simply auto-self-deployment). This is not a disadvantage or negative, it's just a necessity when you have custom code. You could deploy your solution to an image then run it scalable on Azure or AWS, as Hangfire will simply add them as new servers available to process tasks, but the whole point of a scalable service is that it can run on separate resources to allow parallelism. Funneling it back into a webAPI seems to defeat the purpose of a scalable solution.

There is no monthly subscription and there won't be until at least mid to late 2025

@@nickchapsas sad

That's not the job of *any* external library, that's the job of your application code Polly is a nice library to do that

Not to my knoledge no, it isn't the usage intended. Hangfire uses code static anylisis to serialize the code needed to be executed. How would you do that in a web form ?

Yes. Hangfire separates the client (job scheduling) from the server(s) (job processing). They don't have to run on the same host. Common approach is to deploy a Windows Service as a server instance. You can have multiple servers that are processing the jobs. They just need access to the Hangfire data storage. And for each server you can specify if it should only process jobs from specific queues (default is to process from all queues).

Cannot do scheluding, i.e. executing code in the future or every monday at 6

You can use the SideCar pattern for that. Basically you have one specific service that has those infos, and you call that service when needed. By means of webApi or messaging.

yeah, this makes sense in certain scenarios, however I pretended to use Hangfire as a separated pod or as a separated service, to manage scheduled services across organization, maybe is not intended for this scenario.

Yes

Concurrencies and retries are not Hangfire's responsibility but your code's. It is not meant for executing complex code. Call a webApi if you need to do that.

@@RaMz00zWhy does it have concurrency and retry attributes then?

Yup, TimeZoneInfo is an optional parameter when scheduling recurring jobs

Care to elaborate? I though parallel jobs with Hangfire were kinda the thing it was supposed to do (other than scheduling) based on the worker count? Maybe I have misunderstood something.

Hangfire sends an ID that you can cancel as well.

Doesn't do any deleting by default, but there's a param for that

You can setup a cleaning policy on the server (I'm pretty sure). Or just clean the database yourself.

@@RaMz00z yes, that is one of the way but it does not help for case like you want to process thousands of data on a day and you just want to monitor of what went well and what went wrong. You open the dashboard and it feels really slow.

It's not intended for background threads but for scheduling. Even tho it can effectively do that as well

Postman alternative.

Rider

Rider

What kind of issues have you had?

Not invented here, why use other people http servers and messaging frameworks, when you can do it yourself.

@@AndersReinhardtHansen My point is that you can easily write a scheduler that does the job instead of using a library that either contains a massive amount of overhead or doesn't to the job you expect it to do.

Agreed. The only reason I tested Hangfire but was using Quartz in the end, was the convenience of CRON expression. However, even Quartz generated some headaches, which motivates me to make an own scheduler. The mess with timers in .NET and how to pick the right one, was the "hardest" part of it. If you need a scheduler only, build one and sleep well.

@@fusedqyou yeah and that is my point, you cannot make a better scheduler in the time it takes to setup a hangfire job. There is also the added advantage in the fact that if you have used hangfire before it is even faster yo setup and read the code.

@@AndersReinhardtHansen I think this is up for debate. Most people can just write a simple timer to satisfy their needs of a scheduler. I didn't spend longer than a day to write a basic scheduler that handles multiple tasks in a specific interval, so if there was an actual tutorial on it then anybody could make one.

Started in Russia, they are now in Estonia. Same with Jetbrains, do you stop using Jetbrains as well?

I thnk hangfire is free are

@@guy-heylens they moved during the war, jetbrains before. It was not my choice not to use it. The decision was done in the purchase department. And at that time the company was based in Russia, they were writing a blog about moving to Estonia.

​@@xelesarc1680the basic version yes. I needed the pro version.

What stupid reasons, just because it is "Russian" software. What a pathetic world we lived in? We wouldn't even have to use American software at this point if we were consistent