Обработка недопустимых сообщений потребителям весной AMQP

Question

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

Как избежать этой ситуации? Или, другими словами, как ограничить повторение до ограниченного числа раз?

Я пробовал шаблон повтора с шаблоном кролика, но без успеха. Вы можете найти конфигурацию ниже:

<rabbit:template id="rabbitTemplate" connection-factory="connectionFactory" reply-timeout="10" retry-template="retryTemplate"/> 

<bean id="retryTemplate" class="org.springframework.retry.support.RetryTemplate"> 
<property name="backOffPolicy"> 
    <bean class="org.springframework.retry.backoff.ExponentialBackOffPolicy"> 
     <property name="initialInterval" value="500" /> 
     <property name="multiplier" value="10.0" /> 
     <property name="maxInterval" value="10000" /> 
    </bean> 
</property> 
</bean> 

я упомянул эту статью для моей проблемы: Handling AMQP messages gracefully with spring-amqp

Answer 1

Использования шаблона повторных попыток с помощью шаблона кролика для повтора публикации сообщений и не имеет ничего общего с потреблением (если вы не используете template.receive().

Чтобы добавить повтор и прервать контейнер-слушатель, см. the documentation. Вам нужно добавить перехватчик повтора в цепочку консультаций контейнера слушателя; если в ваших сообщениях нет идентификатора сообщения, вам нужно использовать повторение без сохранения состояния, потому что инфраструктура должна знать, сколько раз сообщение было повторно выполнено, а amqp не предоставляет эту информацию.

См. discussion о том, что делать, если повторные попытки исчерпаны. По умолчанию сообщение только регистрируется и удаляется, но вы можете настроить соответствующий восстановитель. RejectAndDontRequeueRecoverer отклонит его, и кролик может быть настроен для отправки сообщения на обмен мертвой буквой/очереди. Или вы можете использовать RepublishMessageRecoverer для записи сообщения в другую очередь, включая информацию о сбое.

См. Например, this question/answer. Но учтите, что использование восстановления состояния с помощью случайного идентификатора сообщения не будет работать.