Как отключить счетчик предварительной выборки RabbitMQ с помощью SimpleMessageListenerContainer

RabbitMQ предлагает возможность дополнительно установить счетчик предварительной выборки.

Используя spring-amqp SimpleMessageListenerContainer, я заметил, что счетчик предварительной выборки всегда установлен. Я не могу установить счетчик предварительной выборки на 0, потому что SimpleMessageListenerContainer устанавливает его как минимум на txSize, который должен быть больше нуля (даже если транзакций нет). Итак, есть ли способ отключить счетчик предварительной выборки, то есть сделать его неограниченным?

Вот соответствующий код из spring-amqp:

SimpleMessageListenerContainer.createBlockingQueueConsumer() делает это:

    int actualPrefetchCount = prefetchCount > txSize ? prefetchCount : txSize;

и BlockingQueueConsumer.start() делает это:

    if (!acknowledgeMode.isAutoAck()) {
        // Set basicQos before calling basicConsume (otherwise if we are not acking the broker
        // will send blocks of 100 messages)
        try {
            channel.basicQos(prefetchCount);
        }

Какова причина всегда вызывать basicQos() в Springs BlockingQueueConsumer? Нет ли какого-либо варианта использования для отключения подсчета предварительной выборки? (кроме автоподтверждения, очевидно).

Документация rabbitmq обсуждает накладные расходы, связанные с установкой счетчика предварительной выборки с канальной (глобальной) областью действия. Явно не упоминается, имеет ли установка его с областью действия потребителя какие-либо накладные расходы по сравнению с тем, чтобы не устанавливать его вообще. Если не ошибаюсь, весна всегда ставит его с потребительским размахом. У него действительно нет накладных расходов? Тем не менее кажется странным отсутствие возможности не устанавливать его.

Спасибо


java rabbitmq spring spring-rabbit spring-amqp
person Nazaret K.    schedule 11.06.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Поскольку текущая реализация переключается во внутреннюю очередь, из-за того, как работали более ранние клиенты RabbitMQ, отсутствие установки qos приведет к состоянию OOM, если потребитель не сможет идти в ногу.

На самом деле, в более ранних версиях Spring AMQP это происходило с автоматическим подтверждением, поэтому очередь ограничивалась в соответствии с размером предварительной выборки, чтобы брокер не мог отправлять сообщения в этом состоянии.

В версии 2.0 мы планируем новую реализацию контейнера, которая избегает этой очереди, так как клиент-кролик не больше не имеет проблем, которые требовали этого. Тогда мы можем рассмотреть возможность поддержки qos=0.

person Gary Russell    schedule 12.06.2016
comment
Хорошо я понял. Это отвечает на мой вопрос. Когда вы говорите удалить внутреннюю очередь, вы имеете в виду заменить ее на com.rabbitmq.client.QueueingConsumer клиента rabbitmq? Потому что в этом случае вы все равно получите OOM, если приложение не устанавливает qos и не может идти в ногу, верно? Кроме того, вы случайно не знаете, есть ли на самом деле какие-либо накладные расходы при установке счетчика предварительной выборки (на уровне потребителя)? Спасибо еще раз. - person Nazaret K.; 12.06.2016
comment
Если подумать, я не думаю, что вы имеете в виду заменить его на com.rabbitmq.client.QueueingConsumer, потому что это будет своего рода эквивалентом. Я думаю, вы имеете в виду, что новая реализация контейнера будет напрямую использовать клиент Rabbit, что означает собственный пул потоков для отправки потребителям и собственный WorkPool в качестве внутренней очереди. - person Nazaret K.; 12.06.2016
comment
Точно. Перейдите по PR-ссылке из этой JIRA на PoC, который я сделал недавно. Он неполный, но подтверждает концепцию. - person Gary Russell; 12.06.2016
comment
Я не знаю ответа на ваш вопрос. Спросите у парней rabbitmq в группе Rabbitmq-users google. - person Gary Russell; 12.06.2016