Question

unkn0wn8 on Tue, 07 Feb 2017 13:04:44


Hello,

We use an azure service bus queue with an Azure webjob using the Azure WebJobs SDK.

Unfortunately, the webjobs throw exceptions with the following stack trace :

Unhandled Exception: Microsoft.WindowsAzure.Storage.StorageException: The remote name could not be resolved: 'appname.queue.core.windows.net' ---> System.Net.WebException: The remote name could not be resolved: 'appname.queue.core.windows.net' 

We can see here that the webjob tries to connect to a storage account queue instead of the service bus queue. If we change the shared access key to a non-existing one, here is the error : 

Unhandled Exception: System.UnauthorizedAccessException: The remote server returned an error: (401) Unauthorized. claim is empty. TrackingId:8894686d-e088-43ff-a198-5743961ad7fc_G9, SystemTracker:appname.servicebus.windows.net:documents-queue, Timestamp:2/7/2017 1:01:53 PM ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.

Here the service bus queue connection string seems correct so why is the webjob trying to use the storage account queue insted of the service bus queue ?

Thank you


Sponsored



Replies

Sheethal J S on Wed, 08 Feb 2017 05:42:49


Please refer the below links and try the work around which might help you.

https://docs.microsoft.com/en-us/azure/app-service-web/websites-dotnet-webjobs-sdk-service-bus

https://github.com/Azure/azure-webjobs-sdk

Feel free to post back if you have more questions.

unkn0wn8 on Wed, 08 Feb 2017 13:50:04


Thanks for your reply.

Unfortunately, after multiple tests following the procedure on the links you provided, I still receive this error in the webjob : 

Unhandled Exception: Microsoft.WindowsAzure.Storage.StorageException: The remote name could not be resolved: 'appname.queue.core.windows.net' ---> System.Net.WebException: The remote name could not be resolved: 'appname.queue.core.windows.net'

The error is logical since we do not have a Storage Queue at this address but what i don't understand is why the webjobs tries to connect to it instead of the Service Bus queue which exists and is correctly defined in the webjob configuration file.

Does someone have an idea ?

Thank you


Sheethal J S on Thu, 09 Feb 2017 07:39:19


Can you include some code snippets? It's not even clear that you're using the correct library.  Are you using the Azure Storage Queues library to try to talk to Azure ServiceBus Queues? That won't work.

You mention the error Microsoft.WindowsAzure.Storage.StorageException. This exception type isn't from any Azure ServiceBus Queue client library.

It looks like the you are mixing up the Service Bus and Storage Queues model, which are distinct

Check the below links for more information.

https://docs.microsoft.com/en-us/azure/app-service-web/websites-dotnet-webjobs-sdk-service-bus

https://docs.microsoft.com/en-us/azure/app-service-web/websites-dotnet-webjobs-sdk-storage-queues-how-to

QueueTriggers work with Storage, ServiceBusTriggers work with SB Queues

unkn0wn8 on Thu, 09 Feb 2017 11:31:27


Here is the code :

Program.cs

public class Program
    {
        // Please set the following connection strings in app.config for this WebJob to run:
        // AzureWebJobsDashboard and AzureWebJobsStorage
        public static void Main()
        {
            try
            {
                var MaxConcurrentThreads = 4;
                var config = new JobHostConfiguration();
                config.NameResolver = new SettingsNameResolver();
                var serviceBusConfig = new ServiceBusConfiguration
                {
                    MessageOptions = new Microsoft.ServiceBus.Messaging.OnMessageOptions
                    {
                        AutoComplete = true,
                        MaxConcurrentCalls = MaxConcurrentThreads,
                        AutoRenewTimeout = TimeSpan.FromHours(1)
                    }
                };
                ServicePointManager.DefaultConnectionLimit = MaxConcurrentThreads;

                config.UseServiceBus(serviceBusConfig);
                var host = new JobHost(config);
                // The following code ensures that the WebJob will be running continuously
                host.RunAndBlock();
            }
            catch (Exception ex)
            {
                Console.WriteLine("Error in Main : " + ex.Message + ex.StackTrace);
                throw;
            }
        }
    }



Functions.cs : 

public class Functions
    {
        public static async Task ProcessDocsAync([ServiceBusTrigger("%documentProcessQueueName%")] BrokeredMessage message, TextWriter log)
        {

              //Our code

        }

    }

In the App.config file, we have these entries : 
<connectionStrings>
<add name="AzureWebJobsDashboard" connectionString="" />
<add name="AzureWebJobsStorage" connectionString="" />
<add name="AzureWebJobsServiceBus" connectionString="" />
</connectionStrings>
<appSettings>
<add key="documentProcessQueueName" value="documenttoprocess" />
</appSettings>

We use the Azure WebJobs SDK to communicate with the Service Bus Queue. We do not use any Azure Storage client library directly in the code as you can see above.

What are we missing ?

Thanks for your help


unkn0wn8 on Thu, 09 Feb 2017 15:07:19


One more thing I've just discovered is when I send a test message in the queue using Visual Studio Server Explorer, I can see in the webjobs logs the message is received and the function is executed successfully but when there is no message in the queue, the error above (StorageException) occurs.

I don't know if that helps.

Thanks

clemensv on Fri, 10 Feb 2017 07:58:32


There's a red herring here. Probably a school of herrings.

The error you're getting regarding storage can't be from the Service Bus API since it takes no dependencies on storage. The unhandled exception you're quoting above does not stem from the Service Bus code path. 

What's particularly suspicious here is that the exception refers to "appname.queue.core.windows.net", which clearly isn't Service Bus. And a key change then points to appname.servicebus.windows.net. That's either a mixup of the connection strings you use or there is a real bug in the Web Jobs SDK. 

This isn't something we can help with in this forum. We'll move this question to the forum for Azure App Service  and I hope that the issue can be resolved there. The more expedient way will be to raise a support request through the Azure Portal.