Использование prefetch count

Встал вопрос о том, что неплохо бы предусмотреть пакетирование сообщений принятых из реббита, и конечно же сразу подумалось про параметр prefetch count, который позволяет получать на клиента сразу необходимое количество сообщений из очереди.
Решили попробовать, и стало непонятно, а как нам получить из очереди несколько сообщений, обработать и отдать им всем после этого ack?

Например такой код:

Компонента = ОчередьСообщений.ПолучитьЭкземплярКомпоненты();

КлючПотребителя = Компонента.НачатьЧтение(“testqueue”, , Ложь, , 5);

Данные = Неопределено;

Пока Компонента.ПолучитьСообщение(КлючПотребителя, Данные, 1*1000) Цикл
Сообщить(Данные);
Компонента.ПодтвердитьСообщение();
КонецЦикла;

Работает так, что после каждого подтвержденного сообщения, на клиент приезжает еще одно и так продолжается до полной вычитки.

Если убрать из этого кода

Компонента.ПодтвердитьСообщение();

то вычитываем 5, останавливаемся по таймауту, серверу уходит noack и уже не можем отослать 5 подтверждений, как написано в документации:

Отсылает серверу подтверждение (ack), что сообщение обработано и его можно удалить.
В API жестко зашит порядок обработки сообщений. Подтвердить можно только последнее прочитанное сообщение.
Таким образом, если prefetchCount больше единицы, то отправлять ack нужно по принципу LIFO (стеком).

Как это должно работать? Кто нибудь пользовался?

https://www.rabbitmq.com/nack.html

To solve this, RabbitMQ supports the basic.nack method that provides
 all the functionality of basic.reject whilst also 
allowing for bulk processing of messages.

Нас я так понял интересует именно слово BULK

https://www.rabbitmq.com/confirms.html

Вообще там еще и QoS светится… Короче надо погонять пример - не раньше 1.4 появится, уж извини @Bronislav - тут так просто не получится.

P.S. @EvilBeaver видал BasicNack() метод ?

Не совсем понял, разве не с помощью QoS текущий prefetch ставится?
И метод ack на сайте описывается, что возможно подтверждать несколько сообщений.
Не получится моя задумка в том виде библиотеки, которая есть сейчас?

UPD: удалил неверно написанное.

На сейчас работает ровно как в документации - подтверждает только последнее полученное. А фраза из документации “Таким образом, если prefetchCount больше единицы, то отправлять ack нужно по принципу LIFO (стеком).” довольно путанно написана. Имелось в виду, что ack надо делать на полученное и не читать методом Consume других сообщений до отправки ack на текущее сообщение.

В следующей версии протокол в части ack(,multiple) будет поддержан

1 Симпатия

А когда примерно ждать следующую версию?

image

Собственно - щас свойства допилятся, отладятся и вперед. Я сейчас скажу что на этой неделе “очень хочется”, но пока @EvilBeaver отмашку не даст - выпуск не поедет

1 Симпатия