Почему Azure Service Fabric не доставляет все сообщения, а локальный кластер -? - PullRequest
Новая
       22

Почему Azure Service Fabric не доставляет все сообщения, а локальный кластер -?

0 голосов
/ 10 мая 2018

Я использую библиотеку C # NetMQ. У меня есть служба продюсера и потребителя, развернутая в Azure с использованием служб с сохранением состояния Service Fabric. У меня есть обе службы разделены так, что есть два экземпляра каждого.

Каждый экземпляр производителя создает PublisherSocket и вызывает Bind. Первое связывается с (например) tcp://10.0.0.1:9501, а второе с tcp://10.0.0.2:9502. (Порты остаются уникальными, поскольку SF может перебалансировать два экземпляра для работы на одном физическом узле.)

Они публикуют какую-то произвольную тему (не имеет отношения к этому вопросу). (Я звоню SendMultipartMessage и передаю NetMQMessage с несколькими кадрами данных.)

Каждый экземпляр потребителя создает SubscriberSocket и вызывает Connect. Каждый из них подключается к обоим адресам производителя. Затем они вызывают Subscribe и передают пустую строку "" в качестве темы. Это должно заставить их использовать все сообщения, отправленные любым из производителей.

Ожидаемые результаты:

  1. Оба производителя связываются, и оба потребителя подключаются / подписываются.
  2. Producer1 отправляет сообщение A, а Producer2 отправляет сообщение B.
  3. Consumer1 получает и A, и B.
  4. Consumer2 получает и A, и B.

Фактические результаты для локального кластера SF : Все как положено. Оба потребителя получают все сообщения от обоих производителей.

Фактические результаты для SF-кластера, работающего в Azure :

  1. Привязка / подключение / подписка - все это происходит без исключения или очевидно ошибка.
  2. Производители отправляют сообщения без ошибок.
  3. Оба потребителя получают сообщения от производителя 1.
  4. Ни один потребитель не получает сообщений от Producer2.

Примечания:

  • Производство находится в цикле, так что это не какая-то странная проблема при запуске.
  • Увеличение количества производителей / потребителей (например, по 5 экземпляров каждого) приводит к тому, что сообщения сначала производителя всегда потребляются, а затем некоторые сообщений других производителей составляют потребляются. Приблизительно половина всех сообщений потребляется, но я не вижу никакой очевидной картины.

Вопросы:

  1. Есть ли что-то странное в комбинации кластера Service Fabric, работающей в Azure, плюс ZeroMQ, которая вызывает проблемы с ZeroMQ?
  2. Есть ли какие-либо опции сокетов ZeroMQ, которые я должен установить?
  3. Есть ли в SF что-то, что я могу изменить?

Любые идеи приветствуются.

...