Ошибка подключения к Azure WebJob DB Только в некоторых случаях

Question

У меня есть два Azure WebJobs. Первый принимает входящее сообщение, которое сообщает ему, чтобы он захватил PDF-файл и разбил его на отдельные изображения страниц, а затем отправил очередное сообщение для второго WebJob для обработки отдельных страниц. Он отлично работал на нашем экземпляре QC, но когда мы попытались перейти к производству, я начал получать странные ошибки во второй работе, но не последовательно. Первое задание выполняется и разбивает файл на изображения страниц. Это прекрасно работает. Я подтвердил, что каждый образ страницы создается и каждое сообщение в очереди попадает в очередь. Однако для второго задания обрабатываются только некоторые из сообщений. Оставшийся показать это ошибка в диагностике WebJob:

Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Exception while executing function: Functions.ProcessBatchPage ---> System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 52 - Unable to locate a Local Database Runtime installation. Verify that SQL Server Express is properly installed and that the Local Database Runtime feature is enabled.) ---> System.ComponentModel.Win32Exception: The system cannot find the file specified

Но что странно, что эта ошибка упоминает локальной базы данных Время воспроизведения и SQL Server Express, и я не ссылки либо где-нибудь в моем коде. Система указывает на базу данных Azure SQL. Задание - это ADO.Net, и я жестко закодировал строку подключения, чтобы попытаться устранить любые проблемы с строками подключения на основе конфигурации. Но странно, что это происходит только с определенной частью сообщений. Остальные работают отлично.

Наконец, я запустил задание в локальном отладке (все еще указывая на настоящую очередь и базу данных на Azure) и получил ту же проблему. Но задание выводит консольную строку с идентификатором задания в качестве первой строки кода. Для тех рабочих мест, которые успешно работают, я вижу эту статью. Для тех, кто терпит неудачу, я никогда ничего не вижу. Это похоже на то, что работа на самом деле не начинается правильно. (Неудачные работы также имеет очень короткое время работы 50-100ms)

Answer 1

Я была такая же проблема с некоторыми рабочими местами, и я наткнулся на этих статьи, чтобы найти решение:

• Transient Fault Handling (Building Real-World Cloud Apps with Azure)
• Connection Resiliency/Retry Logic (EF6 onwards)

Из тезисов статей:

Причины кратковременных сбоев:

В облачной среде вы обнаружите, что соединения с отказами и сбросами данных происходят периодически. Отчасти это связано с тем, что вы выполняете больше балансировщика нагрузки по сравнению с локальной средой, где ваш веб-сервер и сервер базы данных имеют прямое физическое соединение. Кроме того, иногда, когда вы зависите от службы с несколькими арендаторами, вы увидите, что вызовы службы становятся медленнее или тайм-аут, потому что кто-то, кто использует эту услугу, сильно ударяет по ней. В других случаях вы можете быть пользователем, который слишком часто пользуется услугой, а служба преднамеренно дросселирует вас - отказывает в подключении - чтобы вы не оказали негативного влияния на других арендаторов услуги.

Использование смарт-повтора/обратно от логики, чтобы смягчить эффект переходных неудач:

Шаблоны Microsoft & Practices группа имеет Transient Fault Handling Application Block, который делает все для вас, если вы используете ADO.NET для доступа к базе данных SQL (не через Entity Framework).Вы просто установить политику для повторных попыток - сколько раз попробовать повторить запрос или команду и как долго ждать между попытками - и обернуть код SQL в использовании блока:

public void HandleTransients() 
{ 
    var connStr = "some database"; 
    var _policy = RetryPolicy.Create < SqlAzureTransientErrorDetectionStrategy(
    retryCount: 3, 
    retryInterval: TimeSpan.FromSeconds(5)); 

    using (var conn = new ReliableSqlConnection(connStr, _policy)) 
    { 
     // Do SQL stuff here. 
    } 
} 

При использовании Entity Framework вы, как правило, не работаете напрямую с SQL-соединениями, поэтому вы не можете использовать этот пакет патчей и практик, но Entity Framework 6 строит подобную логику повтора прямо в рамках. Аналогичным образом вы указываете стратегию повтора, а затем EF использует эту стратегию всякий раз, когда обращается к базе данных.

To use this feature in the Fix It app, all we have to do is add a class that derives from DbConfiguration and turn on the retry logic.

// EF follows a Code based Configuration model and will look for a class that 
// derives from DbConfiguration for executing any Connection Resiliency strategies 
public class EFConfiguration : DbConfiguration 
{ 
    public EFConfiguration() 
    { 
     AddExecutionStrategy(() => new SqlAzureExecutionStrategy()); 
    } 
}