Ситуация
— есть topic в Azure Service Bus
— используются сессии, т.к. очередность важна
— сообщения перед отправкой в топик получают SessionId исходя из данных самого сообщения (т.е. SessionId генерируются на лету)
— количество и частота сообщений для каждого SessionId не известны, а частота еще и не постоянна

Проблема:
при сбое в обработке сообщения необходимо отложить на определенное время дальнейшую обработку не только сообщения, но и всей очереди с сохранением порядка сообщений

Для получения сейчас используется вариант IMessageSessionAsyncHandlerFactory

message.Abandon() или пересоздание сообщения c указанием задержки не варианты, т.к. текущее сообщение станет последним в очереди. Да и остальные сообщения сессии это не задержит.
Так же вычитать всю сессию не подходит. Если сообщения приходят быстро, то есть большая вероятность что после вычитывания всей сессии и до ее повторной публикации в topic успеют добавиться новые сообщения.
Можно приостанавливать получающий handler, но число handler конечно. Это приводит к уменьшению скорости обработки, а теоретически могут "встать" все handler (если в каждом будет по сбою)

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

Здравствуйте, Doc, Вы писали:


Doc>message.Abandon() или пересоздание сообщения c указанием задержки не варианты, т.к. текущее сообщение станет последним в очереди. Да и остальные сообщения сессии это не задержит.

НЯП, при peek-and-loсk abandon не кладёт сообщение в конец очереди. Снимается блокировка и увеличивается счётчик delivery count. Т.е. должно работать, но при большом количестве сбоев сообщения уходят в deadletter.
Если сообщения обрабатываются не по порядку, то это может быть связано с prefetch.

Стратегия обработки зависит от требуемой пропускной способности. Сообщение в секунду и сотня-тысяча в секунду несколько разные ограничения накладывают
Для первого случая я бы сделал свой message loop, в нём используем long polling для ожидания сообщения, prefetch не используем. При захвате сообщения не забываем про lock renew (обычно таймером + cancellation token делается). Троттлинг к такому велосипеду прикрутить как нефигделать.

Здравствуйте, Sinix, Вы писали:

S>НЯП, при peek-and-loсk abandon не кладёт сообщение в конец очереди. Снимается блокировка и увеличивается счётчик delivery count. Т.е. должно работать, но при большом количестве сбоев сообщения уходят в deadletter.
S>Если сообщения обрабатываются не по порядку, то это может быть связано с prefetch.

Точно. Поглядел — есть prefetch у самой библиотеки SB. Видимо по дефолту стоит 10. Можно отключить, но все равно в сообщение задержку добавить не получится.

S>Стратегия обработки зависит от требуемой пропускной способности. Сообщение в секунду и сотня-тысяча в секунду несколько разные ограничения накладывают

Наверное стоит ориентироваться на 100 в сек для текущих условий (с перспективой роста).

S>Для первого случая я бы сделал свой message loop, в нём используем long polling для ожидания сообщения, prefetch не используем. При захвате сообщения не забываем про lock renew (обычно таймером + cancellation token делается). Троттлинг к такому велосипеду прикрутить как нефигделать.

Видимо да, наверное придется сочинять свой вариант ридера.