Приложение Logi c, завершающее сообщение в служебной шине, подписка topi c с сеансами не снимает блокировку

Question

У меня подписка topi c на служебной шине в Azure с продолжительностью блокировки 30 секунд и включенными сеансами.

Я использую приложение logi c, чтобы получать сообщения topi c, используя пиковую блокировку, потому что я забочусь о порядке обработки сообщений. Я хочу убедиться, что все сообщения с одинаковым идентификатором сеанса обрабатываются в порядке их добавления в шину, например FIFO.

Ниже приведен снимок экрана простого приложения logi c, которое запускается при получении сообщения. приходит (peek-lock с 5-секундным опросом), затем ждет 15 секунд, прежде чем завершить сообщение.

Когда я загружаю 10 сообщений в topi c, первый экземпляр приложения logi c запускается, как и следовало ожидать, и завершается примерно через 15 секунд, однако второе приложение logi c не запускается в течение еще 15 секунд, т.е. всего 30 секунд после запуска первого приложения logi c (длительность блокировки).

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

Answer 1

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

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

Сценарий 1 :

Однако я попытался воспроизвести ваш рабочий процесс с небольшим изменением в Topi. c Subscription Lock Duration, как 2 минуты (чтобы увидеть, влияет ли свойство LockDuration на триггер LA) и предоставил SessionID вручную. Ниже приведен мой результат теста.

Я загрузил первые 10 сообщений в топи c.

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

Сценарий 2: В этом случае я сохранил ту же конфигурацию, но изменил SessionId на " NextAvailable ". Теперь триггер приложения Logi c ожидает всю длительность блокировки (2 минуты и даже больше) и запускает следующий экземпляр.

In В заключение, если у вас тот же идентификатор сеанса для ваших сообщений и вы настроили идентификатор сеанса как «Следующий доступный» в вашем пользовательском интерфейсе LA, то он блокирует сообщение на весь период времени LockDuration. Если вы хотите избежать этого, вам нужно «закрыть сеанс в очереди» на стороне клиента. Это немедленно снимет блокировку и немедленно обработает следующий экземпляр.