During development of my webjob i have redeployed it multiple times to Azure. When i visit the webjob dashboard i am greeted by this:
It seems that every webjob deployment gets registered as a new function, deprecating the old one. Searching around how to alter this behaviour (fold all previous functions together with the current one) gives no results.
Does anybody know how to configure the azure webjob dashboard to merge previous functions together if name+arguments are still the same?
The function list/index for a job host exe is based on the fully qualified assembly name. One thing I can think of that might cause the above would be if your assembly name is changing each time you deploy for some reason. Do you have anything like that going on?
Another question: do you have multiple job hosts sharing the same dashboard storage account?
Related
I have an Azure website with several deployment slots. I use Visual Studio to deploy to a Staging slot and then swap this into Production.
My Visual Studio solution contains one project for my web application and another for a continuous WebJob. I used (Right-click project) > Add > Existing Project as Azure WebJob to configure the WebJob to be deployed to the site along with the web application.
My problem is that the WebJob sometimes continues to run old code after a swap. Sometimes it runs the new code on one invocation and then switches back to the old code on the next invocation. I can't seem to figure out a rhyme or reason to this.
This morning, in order to try to find the cause of this, I did the following experiment:
Delete WebJob in Staging.
Delete WebJob in Production.
Deploy web app to Staging.
Verify that WebJob is running new code in Staging.
Swap Staging into Production.
Verify that WebJob no longer appears in Staging and that it now appears in Production.
What I found was that, after step 4, all the WebJob functions started afresh in Staging and were all running the new code. But after I swapped Staging into Production, there were no new invocations of the WebJob in Production, and when I manually invoked it, the old code ran!
What on earth is going on here? How can I totally clear out the old code and ensure the new WebApp code will run in Production?
I did see another thread saying that checking the Exclude files from the App_Data folder box in publishing settings could cause this issue, but I do not have it checked.
I feel like I'm taking crazy pills here. Any pointers would be sincerely appreciated.
Update 1: As described in my comment below, I have given up and switched to Azure Functions, but I just thought of something that might help anyone else who is encountering this. I recall that at least once or twice, I deployed my WebJob by manually uploading a zip file as opposed to deploying via Visual Studio. I'm starting to wonder if perhaps, under the covers, there is a different code path in use that could give rise to this behavior. Perhaps that will be a useful pointer for someone.
Update 2: I've figured out what happened. I'm describing this in the hopes that it might help someone in the future.
We have several deployment slots: Staging, Production, and a few others. One such slot is called Replica. Its purpose is to be a replica of Production (same code, same configuration settings). The idea is that, for those weird one-off problems that only repro in Production, you can upload a debug build to the Replica slot and attach a debugger without disrupting Production.
This is useful once in a while, but we didn't use it very frequently. The result was that the code running in the Replica slot, including our WebJob code, gradually got further and further out of date compared to what was running in Production. However, meanwhile, the Replica WebJobs kept running the old code, and since the Replica slot has all the same configuration settings as Production, it was operating on the same data and writing to the same logs as our Production WebJobs. So when I would go look at my Production WebJob logs, I would see output that I knew should no longer be there, and I couldn't figure out why. The rogue code was actually running in another slot that I had forgotten about.
So, mystery solved. This probably means we didn't need to cut everything over to Azure Functions. But I'm still glad that we did. I like them better. I like how we have the option to run them in the same app service as our site or a separate one, and the logging system is better. It feels more modern overall.
Anyway, I hope this helps someone out there.
Usually it is not possible run old code after swap successfully and restart your web app. So you can check the content under site->wwwroot in kudu: https://YourWebApp.scm.azurewebsites.net/DebugConsole to make sure your webjob is correct.
In Azure DevOps I have a build pipeline which creates an archive of a project containing two Azure Functions. I then have a release pipeline which deploys this zip archive to the Function App.
The release pipeline was built using the DevOps template for deploying a Function App.
The release runs without any errors and does deploy the dropped artifact. However, if I then look at the Function App in the portal I see the message
Your app is currently in read only mode because you have source control integration enabled.
I wasn't too concerned about this because I don't intend to modify the code in the portal - my assumption is that the read-only state means that I can't modify the function in the portal, right?
And then I also noticed this...
Why is one of the functions Disabled, and how can I deploy so that it is enabled?
Please enable your function and try again. Deployment should not disable your function, so maybe it was disabled in other way. I tried and it works like this.
It seems the warning is not related to the function status. You can use the Enable and Disable buttons on the function's Overview page. These buttons work by changing the value of the AzureWebJobs.<FUNCTION_NAME>.Disabled app setting. This function-specific setting is created the first time it's disabled.
Check documentation here:
https://learn.microsoft.com/en-us/azure/azure-functions/disable-function#use-the-portal
Regarding the warning, if the function is 'deployed' to Azure, what will be deployed is the compiled file. So this is why it is readonly.
Changes to the code should be done before compiling them into corresponding 'cannot be edited' files, which requires special attention.
But for the modification of the declarative part and the configuration part of the function, this is possible.
Detailed information, you can refer to the following case:
Azure Functions App is Read Only after publishing
I have a webjob as below.
I deployed it via VSTS CICD pipeline.
It should ideally run 1 instance and send only 1 email and stop after that but it runs 2 instances and sends 2 emails like below. As it is triggered job i was hoping only 1 instance would be invoked in azure.
Can anyone suggest me over this?
UPDATE
You can check this post which title is Why is TimerTrigger in AzureWebJob is being triggered twice?.
I’m not sure if this bug is currently fixed, you can raise a support ticket to check you logs.
Since TimerTrigger itself is in singleton mode, this error appears in your code currently. I suggest checking your code to make sure that the code is not executed twice, and then add the Singleton attribute to the method.
I'm not sure if this can solve your problem, you can try it.
PRIVIOUS
You can set your webjob as Singleton.
If your Azure Web Sites site is running on multiple instances and you create a new continuous WebJob, the WebJob will run on all instances by default. (Note that a triggered WebJob will run on just one instance selected at random.)
For more details, you can check the offical document. You also can read other related posts.
I have a console application that has been converted to a Webjob.
There are a lot of functionalities in the webjob that is required to be run once a every night(midnight).
However, there is also a specific need that the same Webjob should be continuously running to do some jobs and be able to queue the requests from multiple users.
As the most of the processes are the same I don't see the point of creating another console application as type "Continuous".
As we have a continuous delivery in azure( when there is a new commit to git the online visual studio builds and release the web app and webjobs automatically).
How can I manage to tell build or release process to create 2 webjobs from the same console application which one of those is scheduled(Triggered) and the other is "Continuous"?
While I was writing up the question, stackoverflow similar questions highlighted me this question : Azure webjob; Scheduled execution as well triggers by queue
It looks like it would be possible to use TimerTrigger in a continuous type to handle both cases.
I will try to see if that works. Please give your suggestions for this work case.
You should have a single WebJob that is continuous. You can have as many functions that are decorated with TimerTrigger or message triggers as needed to respond to events or execute on a schedule. You are definitely on the right track.
We have an azure webjob that was deployed as on demand. Is there a way to change this to run on a schedule without redeploying?
Not a lot of info out there on this.
I tried creating a new schedule collection like this and adding a job to run the existing webjob, but that didn't seem to work either.
I prefer to do this in the GUI portal, but if its not possible, I'll do it in powershell (if it is possible like that).
(Also, if it can only be changed by redeploying, I need to know that and it effectively answers the question)
To easily add a schedule to your triggered (on demand) webjob add a file called settings.job at the root of your webjob with this content:
{"schedule": "the schedule as a cron expression"}
Find out more about this here
Note: it'll only work properly for Standard or Premium sites and requires you to set the site as always on.
In the end the link in the original post I referenced worked. The thing that was missing for me was the understanding that creating a trigger job in scheduler will not affect the run status (on-demand or scheduled) of the web job itself. In my case it stayed "on-demand", but the schedule was in fact running it.
This should point you in the direction on how to do this via PowerShell. It looks possible to add already existing WebJobs to a scheduler.
Create a Scheduled Azure WebJob with PowerShell