Я запускаю демонстрацию из Github в очередях сеансов служебной шины Azure для функции состояния. Я понимаю, что брокер очереди сеансов будет хранить сообщения в порядке и сможет обрабатывать сообщения с одинаковым идентификатором сеанса для держателя блокировки сеанса (, который обычно является потребителем ).
Пример пытается отправить сообщения с тем же идентификатором сеанса, но сообщения отправляются не по порядку. Но потребитель заинтересован в правильном порядке сообщений. Таким образом, потребитель пытается отложить неправильные сообщения, пока ожидаемое сообщение не появится.
Потребитель отправляет состояние сеанса подобно порядковому номеру сообщений, отложенных в самом предоставлении состояния сеанса.
Но это консольное приложение не может вернуть отложенные сообщения даже с правильным порядковым номером. Я наблюдаю эту проблему только с IMessageSession, тогда как IMessageReceiver API работает просто отлично.
Кроме того, отложенные сообщения могут быть просмотрены, но я также не смог преднамеренно удалить эти проблемы \ необработанные сообщения.
По истечении времени ожидания выдается следующее исключение:
Службе не удалось обработать запрос; Пожалуйста, повторите операцию. Для получения дополнительной информации о типах исключений и надлежащей обработке исключений см. http://go.microsoft.com/fwlink/?LinkId=761101 Ссылка: 1558dedb-24f9-4b6e-bf41-694e6213e7e9, TrackingId :, SystemTracker :: queue: sessionqueue ~ 239, Метка времени: ...
Не могли бы вы уточнить эти аномалии в поведении брокера Service Bus? Заранее благодарим за потраченное время!