It would be great if there was a way to pause a queue. My use case for example:
We’re using Hangfire for sending our emails but have annoying limitations on our email service. There’s a 60 day password policy and a 5 attempt account lock policy in place. When it comes to the 60 days we need to ensure that no emails are sent while we change the password with the service and then update our configuration.
Currently we’re having to do a check on if we can send emails within the job itself but this really feels like the wrong place to be doing this and adds an extra dependency. It would be much simpler if in our admin controller we could write something like:
public ActionMethod PauseEmails()
{
BackgroundJob.PauseQueue("Email");
return View():
}
public ActionMethod ChangeEmailPassword(string newPassword)
{
AppSettings.EmailPassword = newPassword;
BackgroundJob.ResumeQueue("Email");
return View():
}
It sounds like you would still need to perform the checking / error handling in your jobs as the password could be locked at any time. (Or you may loose connection to the service) You could handle the checking in a job filter which could clean it up quite nicely and this could perform your pause logic. You could store the pause state in a database and and check this as part of the job filter to decide if the send should be attempted.
The BackgroundJobServer doesn’t currently have the ability to pause and resume workers, but could be modified to do so easily enough. (It does have start and stop methods, but these have been disabled and marked as obsolete)
There’s some checking that we’d still need in there but issues such as loosing connection are less of an issue (at worst it would result in a failed job that we could restart later). What needs to be avoided is trying to send an email while we are in the process of updating the password as this would result in the account being locked. I’ll look into Background Job Server, any idea why they’ve been disabled?
Well the comments on the obsolete attributes seem to suggest that the intention is for you to dispose of the instance to stop processing and to create a new instance to start processing. To be honest I think I would personally just persist a flag in a database saying that a password change is required and check this when processing the job. Depends on the volume of email jobs though. I think it is the responsibility of your email provider class to decide if it can or can’t send an email. There are many ways to resolve this issue though, many of them correct depending on the scenario.
This is sort of an important feature. Right now there’s no way to stop new jobs from running while allowing the executing jobs to finish and drain. That makes updating code in a live environment with frequent and long running jobs extremely difficult or extremely unprofessional.
I would also like to vote for this. Having a built-in mechanism that allows selected jobs to be paused via the UI would be very helpful during deployment / maintenance times. Or even during fault-finding etc with the scheduled jobs themselves.
The pause should (IMO) make all servers respect the rule when working in a load-balanced / scaled environment.
This is sort of an important feature. Right now there’s no way to stop new jobs from running while allowing the executing jobs to finish and drain. That makes updating code in a live environment with frequent and long running jobs extremely difficult or extremely unprofessional.
We have the same problem with updating code in our live environment. Now we usually have to manually wait till running jobs are finished but while waiting new jobs could be started. Pausing the processing of queued and new jobs is absolutely needed.
Is this a feature that is on the roadmap or is there any other way to do this manually at the moment?