Что означает ошибка HTTP 500 с под-статусом 121?

Question

У меня есть веб-приложение, работающее в Azure, и у меня было несколько отключений, когда сервер не отвечает. Когда я смотрю в журнале IIS, я вижу ошибки HTTP 500 с sc-substatus из 121 а sc-win32-status из 0.

Пропуская все остальные поля, журналы выглядят так, в следующем порядке:

sc-status sc-substatus sc-win32-status
500 121 0

Я не могу найти ссылку на ошибку 500.121 в Интернете.

Answer 1

Я только что получил это от одного из разработчиков программного обеспечения Azure:

121 - это событие тайм-аута, которое в основном означает, что запрос потратил 230 секунд на рабочую виртуальную машину, не инициируя ввод-вывод для чтения / записи в соединении. Весьма вероятно, что это проблема приложения, но это не обязательно так.

Все журналы IIS имеют определенное время, колеблющееся около 230 секунд. Тайна разгадана.

Answer 2

Мы видели ту же проблему.

TLDR

• Мы используем Always Encrypted в базе данных Azure Sql.
• Мы используем хранилище ключей Azure для хранения наших мастер-ключей.
• Мы обнаружили следующую ошибку, зарегистрированную для более старых версий поставщика хранилища ключей Azure: https://support.microsoft.com/en-us/help/4016853/fix-deadlock-when-apps-try-to-acquire-or-refresh-an-authentication-tok
• Мы обновили поставщик хранилища ключей Azure с версии 1.x до последней версии 2.1.0 - https://www.nuget.org/packages/Microsoft.SqlServer.Management.AlwaysEncrypted.AzureKeyVaultProvider/2.1.0

симптомы

• Мы начали получать 500/121 в производстве.
• Все времена ответа были чуть более 230 секунд.
• Проблема всегда возникала на расстоянии 2 часа... иногда немного дольше.

логирование

• Наша собственная регистрация ничего не показала.
• ELMAH ничего не показал.
• Трассировка неудавшегося запроса ничего не показала.
• Единственное указание было в журналах IIS.
• Мы также собрали некоторые трассировки.Net Profiler на вкладке " Диагностика и решение проблем " в службе приложений на портале Azure и включили стеки потоков. Мы заметили, что было несколько потоков, которые делали вещи, связанные с Always Encrypted. Это было просто немного любопытно, но это было то, что, наконец, заставило нас смотреть на Always Encrypted как на преступника.

репродукция

• Этот код был в 4 разных средах.
• Это происходило только в 2 средах.
• У нас не было ничего, что могло бы вызвать это.

Проблема с поддержкой MS

• https://support.microsoft.com/en-us/help/4016853/fix-deadlock-when-apps-try-to-acquire-or-refresh-an-authentication-tok

Рассмотрим следующий сценарий:

You have Microsoft .NET Framework applications that use Always Encrypted in SQL Server 2016 or Azure SQL Database.
The column master keys for these applications are stored in the Azure Key Vault. 

В этом случае приложения испытывают взаимоблокировки. Поэтому приложения перестают отвечать на запросы (зависают) или время ожидания истекает.

Взаимные блокировки могут возникать во время попыток получить или обновить токен аутентификации для хранилища ключей Azure.

Заметки о выпуске Azure Key Vault Provider v2.1.0

• https://www.nuget.org/packages/Microsoft.SqlServer.Management.AlwaysEncrypted.AzureKeyVaultProvider/2.1.0

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