When I log into the server and open dashboard, it shows recurring jobs with the next execution in the past. Within seconds it triggers processes them automatically, but if I don't log in and open the dashboard, the recurring jobs are not triggered.
It appears that Hangfire is running as expected and processing jobs.
Why will it not trigger without me looking at it?
It's a usual problem if a Hangfire server runs in a web application. The jobs are not triggered because the web server has stopped the app due to user inactivity.
By default, Hangfire Server instance in a web application will not be
started until the first user hits your site. Even more, there are some
events that will bring your web application down after some time (I’m
talking about Idle Timeout and different app pool recycling events).
In these cases your recurring tasks and delayed jobs will not be
enqueued, and enqueued jobs will not be processed.
Read the docs to prevent it: Making ASP.NET application always running.
Another solution is to migrate your Hangfire server from a web application to a console app or a windows service.
Related
I develop a web service (.net core) using Hangfire for running some background jobs as scheduled. This service was deployed in IIS and only have ONE responsibility for running schedule job based on the time (4 or 6 or 13 days) means that no accessible from requested outside.
Its working correct as the first deployment by trigger the feature job or set the short schedule job in next some minutes. But when service waiting for the next job about 4 days it it not working automatically until I connected to server for checking. Means that service was not running until someone connecting to.
I think there are a configuration value in IIS. There is a configuration value for timeout value or sleep time value for this service if have no requested to this service for a long time. Or some thing else ?
You can build your Hangfire Server as a separate application (.Net Core) and run it from the command line, that way, it doesn't idle.
I've written a Node app that essentially serves as a Task Scheduler (or cron) to run batch processes on set time intervals using node-schedule. When I run this program locally or on a VM, the process will run continuously and execute my jobs until the process is forcibly killed. When I deploy this app to Azure as an Azure App Service, the process is treated more as a "Web App", and after a period of inactivity on the site (ie no web traffic), Azure kills the process. If I access the "site" via a browser, it kicks it back up again.
It seems as though Azure is tied to the Node app being an express-based "web app" and as far as I can tell, there's not a way to deploy my command line app in a reliable manner. Am I missing something or is there a better way to deploy this application in Azure either via Web App, or another offering? Would really like to avoid having to maintain a VM just for this purpose.
For your immediate problem of idle timeout there is a simple configuration available called Always on. Take a look at the link here - https://learn.microsoft.com/en-us/azure/app-service/web-sites-configure.
Always On. By default, web apps are unloaded if they are idle for some
period of time. This lets the system conserve resources. In Basic or
Standard mode, you can enable Always On to keep the app loaded all the
time. If your app runs continuous WebJobs or runs WebJobs triggered
using a CRON expression, you should enable Always On, or the web jobs
may not run reliably.
Also look at cost implications discussion here - Does the Azure Websites "*Always On" option have any implication on price?
Now whether App Service is the best solution or not for your problem of Task scheduling, is a more subjective and longer discussion, where you need to evaluate multiple offerings that Azure has and your requirements/priorities etc.
Azure has it's own task scheduling service - https://azure.microsoft.com/en-us/services/scheduler/
Scheduler Jobs are very simple to configure from Azure Portal. You can:
Make calls to http/https endpoints (which implicitly gives you multiple ways to solve your problems). Authentication can be done using basic, certificate or AzureAD OAuth Client credentials).
Send messages to Storage queue or Service Bus queue/topic which can then be processed appropriately by other processes.
If those Azure Scheduler capabilities aren't enough and you need something more involved, here is some guidance on the best practices documentation on background jobs - https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs#schedule-driven-triggers
We recently implemented Auto Heal on our Azure account. It restarts itself every once in a while, maybe once per day.
We also noticed that some of our long-running cron jobs (web jobs) were not finishing.
Would an Auto Heal restart also kill any running web jobs? Could that explain why the crons are sometimes failing to finish?
There are two main processes for an Azure web app. There is the w3wp.exe process, which runs the website itself. The second main process is the w3wp.exe scm process, which runs KUDU.
All webjobs run on the w3wp.exe scm process (KUDU). Auto heal only restarts the site w3wp.exe process meaning your web jobs should not be impacted by auto heal. The exception here is that if you web job is pulling data from the main site when the site is recycling, this could cause your web job to fail due to the site being offline for the recycle.
You can observe your site processes by navigating to (replace sitename with your web app name) https://sitename.scm.azurewebsites.net/ProcessExplorer/
One item that you should ensure for long running web jobs is that you have 'always on' enabled. You can turn this feature on in the 'Application settings' blade for your web app.
You can also refer the link Proactive Auto Heal to know more about this feature.
I have a confusion over differences between using app service alone and app service with web jobs.
I have a computation intense task (2-20 min) that must be triggered manually (user asks for it from time to time). Right now everything happens in one app service. I'm thinking to extract this heavy process to a webjob in another app service. This new app service will be empty (no api served) but host this web job, which I'll trigger from first app service.
I'm bothered that second app service will be empty.
Can I use second app service to do the work without using webjobs (just WebApi project)? Or I should stick to webjobs? What would be pros and cons of these two approaches?
In my opinion, we shouldn't compare the web api and web jobs. Because this two things is used for different environment.
The webjobs feature:
Web Jobs can be configured to be manually triggered or run on a
schedule.
Web Jobs can be configured to be Continuously running (aka running constantly, all the time)
Web Jobs can be setup to be Triggered based on events in other Azure Services, such as a new messaged added to a Storage Queue or Service Buss Queue or Topic
Web Jobs can be long running
Web Jobs can be short running
Web Jobs can be implemented in any language as either a command-line executable or script
Azure Web Jobs can be implemented to fill any background processing need.
So if you want to work with background processing and don't want to return the response to any other application. I suggest you could choose webjobs.
The web api is easy to build HTTP services for the customer to get the response.
So this is used to interact with others. So If you want to get the result and used in any other place. You could choose web api.
The web api feature:
Attribute Routing
CORS - Cross Origin Resource Sharing
OWIN (Open Web Interface for .NET) self hosting
Web API OData
...
All in all, if the computation will not interact with others(return the result to customer), I suggest you could choose web jobs.
Right now I have a web job that is Continuos with "Always On". This webjob listens for queue messages and performs actions. Everything works fine but I have to pay for every minute the web job "listens" to commands, isn't it?
I have seen that you can also run a web job on demand but I haven't found any example code on how to execute an on demand web job.
Background: I am running a web crawler inside a web job that receives the URL that should be crawled from a message queue. I would like to minimize the costs.
How can I execute an on demand web job from my ASP.NET website?
Thanks
Since your site is already running on a Standard Instance and the WebJob is running in the same Web Hosting Plan at your site, you are not paying anything additional as both the WebJob (and its host site) and the site itself are running on the same VMs.
You can enable (or leave) Always On enabled and not incur any additional costs. Turning off Always On will not save you any money and as you are aware, it is required for a Continuous WebJob to run properly.
Hope that helps.