4

I recently started using Hangfire to handle my background jobs in an ASP.NET project.

My jobs are involving lots, lots (and lots) of HTTP calls using WebRequest (I may migrate to something else, but that's for later).

While browsing SO on this subject, I stumbled upon people who do async calls in hangfire.

Is there any point in using async/await tasks inside a Hangfire job ? I'm aware that it is a queue, so jobs won't execute concurrently, but since my project has no GUI, is there any reason I would use async/await to do my HTTP calls inside a Hangfire job ?

PS : The requests that are involving a long-running job use the Task "design pattern", so clients won't experience any timeout

Arthur Attout
  • 2,701
  • 2
  • 26
  • 49

1 Answers1

4

You can absolutely use Hangfire to run async methods, and use awaits within those async methods.

The SO question you linked to was making a blocking Wait call on the method passed to Hangfire to be serialized and then later executed by the hangfire service.

This is very different from something like

hangfireClient.Enqueue(() => myClass.RunAsync());

where RunAsync is an async method that contains awaits. 

public async Task<bool> RunAsync() {
    //do your work
    var subJob = new worker();
    return await subJob.DoWork();
}
Mattkwish
  • 753
  • 7
  • 16
  • Okay, I'm ok with the fact that I could do it, but my question was more on **why would I do that** ? – Arthur Attout Apr 27 '18 at 06:58
  • Why would you use Hangfire to execute an async Job? Same reason you would ever use an async method. If the job your executing is more efficient being async. I can give you an example. I use Hangfire to begin integration transactions which involves syncing multiple independent items. Each one of these items’ sync is an async job, and I await their completion within the Hangfire job. – Mattkwish Apr 27 '18 at 13:27
  • 1
    Oh okay, I see with your example how it could be more efficient. But if I only do strictly sequential computations in my jobs, they won't be more efficient if executed in async, so I guess it's not any useful to do it in async – Arthur Attout Apr 28 '18 at 13:56
  • Yep! Hangfire _really_ is a "fire-and-forget" tool, don't let the fact that you kick off methods with tasks confuse you, it's just storing a method and re-executing it at a later time exactly as if you ran it on your machine right then. – Mattkwish Apr 29 '18 at 00:15
  • According to documentation for v 1.6.0 https://www.hangfire.io/blog/2016/07/16/hangfire-1.6.0.html#thats-not-a-real-asynchrony (current is 1.6.20) real aync support would be only in 2.0 release, and currently Task.Wait is under the hood: Please consider this feature as a syntactic sugar. Background processing hasn’t became asynchronous. Internally it was implemented using the Task.Wait method, so workers don’t perform any processing, while waiting for a task completion. Real asynchrony may come in Hangfire 2.0 only, and it requires a lot of breaking changes to the existing types. – Bogdan Mart Oct 02 '18 at 23:28