HangfireIO / Hangfire

An easy way to perform background job processing in .NET and .NET Core applications. No Windows Service or separate process required

Home Page:https://www.hangfire.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Async support for storage API

sergeyzwezdin opened this issue · comments

Modern data access libraries are migrating to async methods in their API. For example, updated MongoDB driver rewritten with async support.

On the other hand, HangFire have synchronous API for internal objects like IStorageConnection, IFetchedJob, IMonitoringApi, IWriteOnlyTransaction and so on.

It forces to use workarounds like AsyncHelper to build custom storage for HangFire.

So my suggestion is to update API in async way (e.g. return Task<TResult> instead of TResult).

I'm suggesting to use async methods too to keep up with the times, but the changes will be introduced in 2.0 version (next year), because of a lot of breaking changes. I'm planning to make background processes async as well (#150) to gain more opportunities from async storage methods.

Really cool news. Do you have an idea about dates at next year? I will need to make these changes for mongo as well.

Any news on async support yet? Just started using Hangfire, but looks like i may have to stop as it seems it does current support my codebase and i aint updating it all to run using non-await calling just to use hangfire

You can use

var task = Task.Run( async ()=>   {
   var x = bleh;
   await y();
   return z;
});

task.Wait();

It's OK (not perfect) from within Hangfire - there won't be any ugly deadlock. However you will have one of Hangfire's thread's waiting on your separately executing Task to finish. Not the end of the world.

You can also use https://github.com/StephenCleary/AsyncEx/wiki/AsyncContext to do something similar.

Having said that, proper async support in v2.0 next year will be awesome :)

+1, @odinserj, per comment above, could you add to the 2.0 issue-milestone?

Till the Hangfire supports async/await, is it a good idea to encapsulate the call of the jobs creations methods within fire and forget APIs such as HostingEnvironment.QueueBackgroundWorkItem or StephenCleary/AspNetBackgroundTasks ?

examples:

HostingEnvironment.QueueBackgroundWorkItem((cancelationToken) => BackgroundJob.Enqueue(() => SomeClass.DoWork()));

or

BackgroundTaskManager.Run(() =>
{
  BackgroundJob.Enqueue(() => SomeClass.DoWork());
});