Azure Webjob using QueueTrigger not polling Queue in new Storage account

0
votes

I have a WebApp with a WebJob (monitoring a queue with QueueTrigger) in Azure that has been working fine for over a year. I'm trying to re-organize some of my Azure resources and would like the WebJob to monitor a different Queue than it has been.

I've created a new (non-classic) storage account and changed my code to insert new messages into the new Queue. I can see new messages showing up in the new Queue but the WebJob is never triggered. (The old queue is in a classic storage account. I don't think that matters, but it has crossed my mind. I have seen some older posts that make me think this used to be a problem, but some newer ones that make me think it's OK.)

My code is pretty straightforward (almost straight out of tutorial). It wants the Queue connection strings in app.config for both AzureWebJobsDashboard and AzureWebJobsStorage, which I have done.

var host = new JobHost();
host.RunAndBlock();

To verify that the new code is being successfully deployed, I have deleted the old WebJob in the Azure portal and verified the file dates in the App_Data\Jobs... folder are current and I've looked at the value of "AzureWebJobsStorage" in the deployed config file and it is the new Queue's connection string.

I finally thought to manually insert a message into the old queue (that none of my code is pointing at any more). Sure enough - when I do that, the WebJob is triggered and runs.

I think changing the connection string values in App.Config should be all that's needed to have it "watch" a new queue, but that doesn't seem to be enough. Does anyone know what else would need to be changed?

1
azure-webjobs

1 Answers

1
votes

So I figured this out. Not only do you have to have the Connection String entries (pointing to the queue) in the App.Config of the WebJob project, but also for the Web Application. I had configured AzureWebJobsDashboard and AzureWebJobsStorage in the Application Settings section of the Web App in the Azure portal.

Those were still pointing to the old queue, and apparently those were the important ones. Once I updated those settings to point to the new queue, it worked as it should.