Служебная шина удаляет подписки на темы без фильтров / правил, если установлен AutoDeleteOnIdle?

2

Добрый день.

Мы используем темы служебной шины в качестве движка для паба/подсистемы. Наша логика заключается в том, что наши сервисы С# подключаются к теме с подпиской. Мы удаляем $ Default (TrueFilter) и устанавливаем AutoDeleteOnIdle равным 5 минутам.

Поскольку другим частям системы нужны вещи, они говорят нашей службе С#: "Мне нужно это". Затем служба С# добавляет новые правила (обычно CorrelationFilter).

Поскольку те же самые части системы больше не нуждаются в вещах, они говорят нашей службе С#: "Мне это больше не нужно". Затем служба С# удаляет соответствующие правила.

Таким образом, подписка на тему все еще может быть подключена (в комплекте с объектом SubscriptionClient), но вообще не иметь никаких правил.

вопрос

Подписки "исчезают", и я не могу понять, почему. В конце концов, у меня есть активная подписка с подключенным экземпляром SubscriptionClient и функцией обратного вызова.

Затем, когда я собираюсь выполнить действие с моим объектом SubscriptionClient, он генерирует исключение MessagingEntityNotFoundException.

Мне казалось, что служебная шина произвольно и произвольно теряет или удаляет мои подписки.

Сервисная шина Определение "холостого хода"

Насколько я понимаю, подписка не является "бездействующей", если существует активное подключение к подписке (в моем случае, через экземпляр SubscriptionClient). Даже если не поступают сообщения, представляющие интерес, оно все равно не простаивает и, следовательно, не удаляется. Если сообщение приходит через день, экземпляр SubscriptionClient получит его.

Это был мой опыт работы с другими частями системы, которые не динамически добавляют/удаляют правила. Это работает довольно хорошо.

Но потом я начал задаваться вопросом:

Несмотря на наличие подключения к подписке, видит ли служебная шина мою подписку бездействующей, поскольку она не имеет правил и, следовательно, не может принимать сообщения? И будет ли служебная шина следовать свойству AutoDeleteOnIdle и удалять его?

Если вышеприведенное верно, тогда будет ли добавление FalseFilter в качестве $ Default поддерживать подписку?

Любое понимание и помощь будут наиболее ценными.

Большое спасибо - Шон

Обновить

Я провел элементарный тест в приложении WinForms, и, похоже, что-то не так с Service Bus. Или, по крайней мере, наш экземпляр Service Bus.

У меня 17 Тем, а именно:

  • d860ffbe-e9c6-4ede-b6e9-959be4373128/уведомит-0
  • d860ffbe-e9c6-4ede-b6e9-959be4373128/уведомит-1
  • ... (вы поняли)
  • d860ffbe-e9c6-4ede-b6e9-959be4373128/уведомит-е
  • d860ffbe-e9c6-4ede-b6e9-959be4373128/уведомит-е
  • d860ffbe-e9c6-4ede-b6e9-959be4373128/уведомит корень

notify-root пересылает все полученные сообщения другим темам уведомлений. Мы делаем это для шардинга.

Так...

Я создал 3 подписки на каждую из тем от 0 до f:

  • Нет правил (я удалил $ Default)
  • TrueFilter (я оставил $ Default как есть)
  • FalseFilter (я установил фильтр по умолчанию на FalseFilter при создании подписки)

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

Для каждой подписки AutoDeleteOnIdle установлено значение TimeSpan.FromMinutes(5).

Я перебираю свои темы, подписки и правила каждую минуту, чтобы увидеть, когда подписки и правила появляются и исчезают.

Наконец, я публиковал сообщение каждую минуту на уведомлении root.

Каждая из 16 подписок с TrueFilter получала сообщение каждую минуту и отображала его в моем приложении WinForms, как и ожидалось.

Через 5 минут сервисная шина автоматически удалила все мои подписки на темы, заканчивающиеся на 0, 1, 2, 4, 5, 6, B, C и F.

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

Примерно через 30 минут темы, оканчивающиеся на 3, 7, 8, 9, A и E, все еще получали сообщения без признаков удаления своих подписок.

Кроме того, служебная шина не удаляла некоторые подписки, которые либо не получали сообщения из-за отсутствия правил, либо из-за наличия FalseFilter. Экземпляры SubscriptionClient же имеют обратный вызов подсоединили через OnMessageAsync. Следует отметить, что те, которые не были удалены, были в той же теме, что и подписки TrueFilter, которые также не были удалены.

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

Я повторил тест, и это были те же самые темы, у которых были удалены их подписки (несмотря на активность).

После того как я прекратил публикацию, служебная шина удалила оставшиеся подписки через 5 минут (как и ожидалось).

Я повторю тест с другим набором из 17 тем.

  • 2
    Похоже, хороший вопрос для команды брокера . А также запрос на обновление документации. Документация XML на самом деле не раскрывает ничего из этого.
  • 0
    Большое спасибо, Шон. Оказывается, это была проблема Azure только в регионе Запад США 2 и затрагивала только некоторые темы. Microsoft работает над исправлением. Я никогда не думал, что у Microsoft есть такая фундаментальная проблема в Service Bus, не говоря уже о том, чтобы она продолжалась в течение нескольких месяцев, не говоря уже о том, чтобы оставаться в одном регионе.
Показать ещё 2 комментария
Теги:
azure
azureservicebus
servicebus
azure-servicebus-topics

1 ответ

0

Оказывается, AutoDeleteOnIdle работает именно так, как я и думал.

Пока подписка на тему имеет соединение, ее не следует удалять. Неважно, есть ли у вас правила, FalseFilter или сообщения не публикуются. Пока у вас есть активное соединение, и вы в настоящее время пытаетесь получать сообщения, используя OnMessage(), OnMessageAsync(), Receive() или ReceiveAsync(), подписка не будет свободна и не будет удалена.

Тем не менее, наши подписки на темы служебной шины все еще исчезали из некоторых тем. Они все еще были удалены во время AutoDeleteOnIdle. Я так и не смог воспроизвести проблему на своей коробке разработчика.

У нас была проблема в нашей производственной среде в последние несколько месяцев, и она только усугубилась. Мы предполагали, что делаем что-то не так.

Так получилось, что сегодня Microsoft подтвердила мне, что эта проблема возникла в западном регионе США. Другие регионы не затронуты. MS не подтвердила, почему это происходит, как долго это происходит или сколько времени потребуется, чтобы исправить это.

Это последнее, что я мог себе представить. Я предположил, что делал что-то не так.

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

Надеюсь, это будет исправлено в ближайшее время.

Если кто-то еще сталкивается с исчезновением или удалением подписок служебной шины, несмотря на активность, я бы рекомендовал создать тест, как и я. Если тест не работает должным образом, обратитесь в Microsoft.

Поделиться
  • 0
    Microsoft решила эту проблему 23 января 2019 года в западном регионе США. Наши тесты подтвердили, что теперь он работает как положено.
  • 0
    Определение бездействия: docs.microsoft.com/en-us/azure/service-bus-messaging/… Кроме того, в своей разработке я периодически теряю подписки, когда ноутбук переходит в спящий режим и, таким образом, теряет соединение на время, превышающее настроенное время ожидания

Ещё вопросы

Сообщество Overcoder
Наверх
Меню