My use case it the following.
I have a system composed by several WCF services (15+). Each of them can fire events (say: “New user created”, “Password changed”, “New PDF file available” and the like).
Each event should trigger a set of actions, that must be run asynchronously, and which should retried in case of failure (for example: perform a call against another WCF service, or try to upload a file to a FTP server with low availability).
I’m evaluate=ing the use of a message broker like ActiveMQ, RabbitMQ or MSMQ, but I wonder if Hangfire could be a viable option.
I can’t understand if the Hangfire is somehow dependent on ASP.NET, which I am not using in this project.
I believe Hangfire would be a reasonable fit to your problem. The only area of concern would be the originating events - What happens if an error occurs while queuing the jobs in Hangfire (Or in anything else) - Can the WCF services re-fire these until they are acknowledged ? Hangfire can queue multiple jobs atomically, but it is a pro feature. (See Atomic Background Job Creation)
Hi, @yngndrw. Thank you very much for the reply.
Could you please elaborate on the area of concern?
What happens if an error occurs while queuing the jobs in Hangfire
I’m not sure I’m understanding the question.
About: "Can the WCF services re-fire these until they are acknowledged ?
I don’t need to fire more events atomically. The atom would be the single event.
May be I should have mentioned that mine is distributed systems: WCF services (that is, the producers of events) are meant to be deployed on different machines. Is it a problem? Reading the documentation I found the reference to the “worker thread”, so I wonder if producers and job worker must reside on the same process or machine. Reading Running multiple server instances it seems to me distributing producers and workers is possibile.
Producers and consumers / workers are separate in Hangfire. Producers can use the Hangfire client API to directly add jobs into the storage provider and the workers can either be run on the same machine or separate machines. Just use the BackgroundJob.Enqueue method to create the jobs on the producers.
My area of concern is around Hangfire not being able to queue the job for some reason. (For example, what if the producer cannot connect to the storage provider for some reason ?) In this case the event will have fired but the related job will not have been queued, which may or may not be a problem for you depending on your use case.
Additionally if you need to create multiple jobs for a single event then Hangfire may fail after creating only some of the jobs for that event so without the Atomic Background Job Creation feature, if you were to re-try the job creation you may end up with some duplicate jobs. (Again, this may or may not be a problem for you depending on your use case) - Am I right in thinking that when you say “I don’t need to fire more events atomically. The atom would be the single event.”, you mean that you don’t require more than one job to be created by a single event ? If so this point is moot, but the previous concern may still be an issue.