Azure Webjobs – good stuff, with a gotcha

One of the really nice things about Azure Webapps is the support for running Webjobs. Most large webapplications will at some point need some data or media processed by a background process, and for that Webjobs are a perfect fit.

Nice and simple

In its simplest form a Webjob is simply a Console application that is deployed as part of the website, which can be configured to run either continously or as a cron job. Not too long ago Microsoft also introduced Azure Functions, which enables some of the same scenarios, but Webjobs are really quite simple, and they enable many more sophisticated scenarios.

Building on the very basics, the Azure SDK enables the application to listen for messages on a queue or new items written to blobstorage. This is great for complicated processing with multiple steps - just have each step listen for a message or blob, and let it push a message or a blob that the next step will then pick up.

The bite

One catch with webjobs is that when they are deployed, the Webjob process on Azure will look for one of a range of file extentions and run the first it comes across. In a scenario where you include other runnable files, this may be an issue, since that other file may be the one that ends up being picked to run. I read somewhere, that a fix was to deploy a run.ps1 file, because that would be picked before any other, and then that file could just call the .exe I wanted to run. This looked like it worked at first, but got me in hot water, because using the Azure SDK bits means that the process keeps running to listen for incomming messages. Now Azure was not able to determine that the process was already running, so a new process was started every time it was scheduled to run. In the end the solution was simply to make sure the .exe was named run.exe - making it take presedence, and allowing Azure to manage it properly.

When something like this happens, the tools section on the Azure Portal and the Kudu tooling is your best friend. The issue here is that when a lot of processes have been spawned, it is not a feasible way to kill then all, and you can't do it using the webbased commandline. So the solution I found was to scale the site down and up again, which forces it to be moved between VM's, killing all the unwanted processes. Some times it is good to remember that there is no cloud - just a computer somewhere else.