Internal RedisClient logging logs all it's exceptions. It is nice, but it logs even failed transactions with the Error level. However, HangFire know that some transaction can fail, so, that is not an error and it can confuse users with the logging turned on.

We should turn of the internal logging and handle (and log) Redis exceptions manually.

As a user, I want to know about all exceptions that occurred during any state transitions. This exceptions may be related to custom filters/handlers that I've added.

To do this, state machine should move the job to the Failed state if it encountered an exception. To minimize risks of getting another exception, it should turn off custom filters while changing the state.

As an administrator, I want to retry all my failed jobs at once. To do this I go to the Failed jobs page and click the "Retry all" button in the top toolbar. When the operation completes, I want to know, how many tasks were re-queued, and how many tasks were not re-queued.

All failed jobs should proceed to the Enqueued state only from Failed state, because someone can change job's state during retry task execution.

HTTP Error 500.23 - Internal Server Error
An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

There is even simpler way to perform tasks asynchronously. Current method is based on used special class (based on BackgroundJob), its special method (Perform) and special manner of arguments specification (using properties). This method provides the full information about what server should do to perform a task.

As I say, there is simpler way to do it, and it is based on expression trees. Server needs to know the exact method to call, including its type and what arguments to provide to it. Expression trees can provide this information. Look at this:

// Calling instance methods
Perform.Async<MyServiceClass>(x => x.SendEmail("Greetings to you!", userId: 5));

// Calling static methods
Perform.Async(() => Console.WriteLine("Hello, world!"));

Signatures of the Perform class methods will look like these:

// For calling instance methods
public static string Perform<T>(Expression<Action<T>> methodCall);

// For calling static methods
public static string Perform(Expression<Action> methodCall);

The body of the methodCall argument expression will contain the instance of the MethodCallExpression class. We can obtain the name and the type of the method. And we can compile expressions that act as method call parameters to evaluate their values. On the server side we could obtain them, try to identify the exact method match and call it via reflection.

Pros.

• Blazing fast start to use the library. You don't even need to define jobs, because you can take your existing methods.
• Clears the way how this library works – it just perform methods asynchronously, but with different features and guarantees.
• There is no need to guess job argument names on the client side.

Cons.

• Possible reduced performance on Client. Expression trees compilation is an expensive operation. However, we could cache the compiled versions.
• Possible reduced performance on Server. Reflection-based method invocation performs slower than raw method invocation.

Simplicity wins there, especially if performance penalty will be low.

HangFire tracks jobs history and this history can contain removed workers.

Redis connectivity errors are typical for new installations. HangFire Monitor should display friendly error page, may be with some instructions to not to confuse new users.

Scheduled jobs are fetched one by one now. Despite of Redis implementation executes much better than SQL Server one, this task can be performed better.
To do this, schedule poller should take top N jobs that need to be enqueued. To prevent unnecessary locks in a multi-server environment, we could shuffle this list. So each server will take random job to enqueue.

Default HangFire installation allows anyone access to Monitor Web UI. Although everyone can change http handler registration to meet this requirement, it is not good to provide security hole with the default setup.

Elmah library authors made deep investigation about this topic, and we could use their implementation.

Default setup should:

• Provide support for allow/deny access for remote users. Default: deny.
• Allow to specify users/roles that are allowed or denied using standard ASP.NET authorization api. Default: allow anyone.

To provide support for multiple queues, I've added some classes (PriotitizedJobFetcher, PrefetchJobFetcher). But I don't know why I wrote them. There should be simple algorithm:

1. Blocking pop from queue 1 with short timeout.
2. Non-blocking pop from queue 2.

...
N. Non-blocking pop from queue N.

Moreover, each worker has its own connection. Why not to use them instead of centralized fetcher?

Currently it takes only full connection string. As a user, I have either to learn how to get a connection string from configuration file (I really forget what class name has configuration manager each time I need it), or simply paste the full connection string as an argument, that will lead to maintenance error.

Hi,
this is awesome library, thanks for it.

is there a possibility to use ravendb as back end storage instead of Redis ?

thanks in advanced.

The documentation states that the default queue will be listened when we creating the instance of the BackgroundJobServer class using its default constructor. However, the system is acting now in a different way.

1. Instantiate the BackgroundJobServer class with the default constructor:

var server = new BackgroundJobServer();
server.Start();

1. The server does not listen to any queue:
   

Turn it into following interfaces:

• IJobStateChangedFilter
• IJobStateAppliedFilter

This script provide (with the server support) target application with the functionality to poll a specified job[s] for their status[es].

API should look like this:

HangFire.Poll('abracadabra-job-id', function (jobId, state) {
    if (state === 'succeeded') console.log('Job succeeded!');
});

This release will provide the following NuGet packages:

• HangFire.Core – Client, Server, Storage abstractions.
• HangFire.Redis – Redis storage implementation.
• HangFire.SqlServer – SQL Server storage implementation.
• HangFire.AspNet – Monitor, ASP.NET HangFire Server.
• HangFire – easy-to-setup package. Contain dependencies to HangFire.AspNet, HangFire.SqlServer and HangFire.Core. Also contain web.config transformation and HangFireConfig.cs class.

1. Create any job in HangFire.Redis storage.
2. Go to the job details page.

Provide developers with the following abilities, that may be applied to a specific job.

• Specify max attempts count, including a ban on a retry
• Override retry delays
• Something else?

This features can be implemented with custom attributes (including the existing one) or with methods that will be called via reflection.

As a developer, I want to include HangFire library reference to signed assemblies.

The order in which filters are applied to some events depends on the order they were added to the GlobalFilters.Filters collection. It is wrong behavior. There should be a possibility for filter developers to set the needed order for their filters, removing this responsibility from filter users.

Check all public classes. Pay special attention to the following cases:

• Queue names exists as a key part in Redis. So, we should impose some restrictions on them. Perhaps, alphanumeric with dash and underscores. Consider about lowercasing them or making them case insensitive.
• Server names are used as a key part in Redis too. Same restrictions as for queue names.

As a HangFire user, I want to see only my classes in the stack trace. So, instead of:

System.Reflection.TargetInvocationException: Адресат вызова создал исключение. ---> System.InvalidOperationException: Выдано исключение типа "System.InvalidOperationException". ---> System.IO.FileLoadException: Не удалось загрузить указанный файл.
   --- Конец трассировки внутреннего стека исключений ---
   в ConsoleSample.Services.Error() в c:\Users\odinserj\Documents\Projects\HangFire\samples\ConsoleSample\Services.cs:строка 26
   --- Конец трассировки внутреннего стека исключений ---
   в HangFire.Server.Performing.JobAsMethodPerformStrategy.Perform() в c:\Users\odinserj\Documents\Projects\HangFire\src\HangFire.Core\Server\Performing\JobAsMethodPerformStrategy.cs:строка 85
   в HangFire.Server.Performing.JobPerformer.<>c__DisplayClass9.<PerformJobWithFilters>b__6() в c:\Users\odinserj\Documents\Projects\HangFire\src\HangFire.Core\Server\Performing\JobPerformer.cs:строка 77
   в HangFire.Server.Performing.JobPerformer.InvokePerformFilter(IServerFilter filter, PerformingContext preContext, Func`1 continuation) в c:\Users\odinserj\Documents\Projects\HangFire\src\HangFire.Core\Server\Performing\JobPerformer.cs:строка 114
   в HangFire.Server.Performing.JobPerformer.<>c__DisplayClass9.<>c__DisplayClassb.<PerformJobWithFilters>b__8() в c:\Users\odinserj\Documents\Projects\HangFire\src\HangFire.Core\Server\Performing\JobPerformer.cs:строка 82
   в HangFire.Server.Performing.JobPerformer.PerformJobWithFilters(PerformContext context, IJobPerformStrategy strategy, IEnumerable`1 filters) в c:\Users\odinserj\Documents\Projects\HangFire\src\HangFire.Core\Server\Performing\JobPerformer.cs:строка 84
   в HangFire.Server.Performing.JobPerformer.PerformJob(PerformContext context, IJobPerformStrategy strategy) в c:\Users\odinserj\Documents\Projects\HangFire\src\HangFire.Core\Server\Performing\JobPerformer.cs:строка 64
   в HangFire.Server.Worker.PerformJob(IStorageConnection connection, JobPayload payload) в c:\Users\odinserj\Documents\Projects\HangFire\src\HangFire.Core\Server\Worker.cs:строка 182

I want:

System.InvalidOperationException: Выдано исключение типа "System.InvalidOperationException". ---> System.IO.FileLoadException: Не удалось загрузить указанный файл.
   --- Конец трассировки внутреннего стека исключений ---
   в ConsoleSample.Services.Error() в c:\Users\odinserj\Documents\Projects\HangFire\samples\ConsoleSample\Services.cs:строка 26

It is awful. Really.

When a server restarts after unexpected shutdown, it re-queues it's processing jobs through the RPOPLPUSH command. However, it does not change the state of the job to the Enqueued, and does not remove it from the hangfire:processing set. So, this can lead to some errors.

It should use standard JobState.Apply method to change the job's state after enqueuing.

Hi,
i am so anxious to use HangFire correctly, but the Docs have so many important and interesting topics that, need to be done so that one can have a full picture of what he is doing, specially for normal developers like me :)

There is no need for additional thread that removes jobs from the processing queue.

Feature list is still open:

• Cron
• ?

Currently the default number of workers determined by Environment.ProcessorCount. This number is good for CPU-intensive work. But when jobs are mostly I/O-intensive, workers would spend much time waiting for completion.
Of course, it would be better to present an async feature that will use IOCP-threads to complete the job, but now it is better just to increase the number of workers.

Check the same file in the MvcSample application.

Hi,

could you please shed some light on this, and is Hangfire a goodstable alternative for nservice Bus, as it is so Huge and Expensive.

thanks in advanced.

SQL Server queue fetching implementation currently uses simple polling technique to get new jobs. This works, but high poll intervals increase the latency of job performance, and low polling intervals increases DB stress.

Service broker could help there, because we can (or if we can) subscribe to receive notifications on new jobs using the SqlDependency class. As I know, it could be used even in the Express edition of the SQL Server.

This task requires more investigation. Moreover, we need to decide how to support it (if it possible) – turn on service broker by automatically or let a user to do this manually. So, we need either to know about negative impacts to SQL Server when this feature is enabled.

It was made obsolete in 0.6. And there is need to prohibit users to add jobs in obsolete format.
Only old Client API will be removed. Your old jobs will be processed.

I have no access to code now, but it is true. You need to check what counters are set within the StatisticsHistoryFiltrrAttribute class and look for those counters, that are not expiring now. Data storage should be always as clean as possible.

I like them, they are awesome, but not as stable as I want. Recent ServiceStack 4.0 release can contain breaking changes. Moreover, it was splitter into signed and unsigned assemblies. They are good in end projects, but I'm in doubt to use them as dependencies.

In 3.9.* there were some breaking changes, that lead to compile-time and run-time errors. I do not want to rush for new versions of dependencies. I want more stable one, and I want signed HangFire assembly. Perhaps, we need to replace them with the following libraries:

• Common.Logging for logging library independent adapters.
• Json.NET as json serialization routines.

ServiceStack.Redis dependency is now used only in HangFire.Redis assembly. It is not hard to support different versions of ServiceStack. Or we could use BookSleeve instead.

When a worker thread is being interrupted by the ThreadAbortException during the job performance, the job should be placed back to its queue. Otherwise its performance will be delayed for the JobTimeout value after the application restart.

They are using the "code" element now. When the total arguments length is a fairy large, the whole table is being stretched outside the page.
You can consider cutting them to a certain length - an administrator can always see them in the Job Details page.

Pages using this element:

• Enqueued page
• Succeeded page
• Processing page
• Scheduled page
• Queues page

It looks very crappy.

SQL Server is a primary data storage for ASP.NET applications. And it is familiar for the most of developers. This implementation will lower barriers to entry for new users, because they do not need to use additional infrastructure for their projects.
SQL Server-based storage should meet all Redis storage requirements, such as installation simplicity, reliability, extensibility and transparency. What remains? Performance. RDBMS are complex, especially when comparing to Redis. And this solution will have performance degradation. But for simple cases it should be enough. When someone requires better job throughput, it could use Redis storage instead.
This work requires storage abstraction first. There are a lot of differences between SQL Server and Redis server. There is need to do full refactoring of a system.

Check statuses, exceptions and monitor ui texts.

Here is the call stack

   в HangFire.Common.States.EnqueuedState.GetQueue(JobMethod method) в c:\Users\odinserj\Documents\Projects\HangFire\HangFire\States\EnqueuedState.cs:строка 65
   в HangFire.Common.States.EnqueuedState.GetProperties(JobMethod data) в c:\Users\odinserj\Documents\Projects\HangFire\HangFire\States\EnqueuedState.cs:строка 39
   в HangFire.States.StateMachine.AppendHistory(IRedisTransaction transaction, StateContext context, JobState state, Boolean appendToJob) в c:\Users\odinserj\Documents\Projects\HangFire\HangFire\States\StateMachine.cs:строка 268
   в HangFire.States.StateMachine.ApplyState(StateApplyingContext context, String oldState, JobState chosenState, IEnumerable`1 stateChangedFilters) в c:\Users\odinserj\Documents\Projects\HangFire\HangFire\States\StateMachine.cs:строка 242
   в HangFire.States.StateMachine.CreateInState(String jobId, JobMethod method, IDictionary`2 parameters, JobState state) в c:\Users\odinserj\Documents\Projects\HangFire\HangFire\States\StateMachine.cs:строка 116
   в HangFire.Client.CreateContext.CreateJob() в c:\Users\odinserj\Documents\Projects\HangFire\HangFire\Client\CreateContext.cs:строка 136
   в HangFire.Client.JobCreator.<>c__DisplayClass9.<CreateWithFilters>b__6() в c:\Users\odinserj\Documents\Projects\HangFire\HangFire\Client\JobCreator.cs:строка 83
   в HangFire.Client.JobCreator.CreateWithFilters(CreateContext context, IEnumerable`1 filters) в c:\Users\odinserj\Documents\Projects\HangFire\HangFire\Client\JobCreator.cs:строка 90
   в HangFire.Client.JobCreator.CreateJob(CreateContext context) в c:\Users\odinserj\Documents\Projects\HangFire\HangFire\Client\JobCreator.cs:строка 57

Otherwise monitor will not show daily and weekly statistics.

This will enable auto-retry functionality for all jobs.