[
https://issues.apache.org/jira/browse/JAMES-3291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151477#comment-17151477
]
Benoit Tellier commented on JAMES-3291:
---------------------------------------
> Every component consuming messages from Rabbit should rely on the dead-letter
> queue feature to put messages triggering bugs in it. `nack` with requeue =
> false does that.
+1 we need to write similar tests and fixes for the EventBus and the
distributed task manager
> We can also allow some retries to prevent transient failures by setting a
> header on the message on failure to count retries.
As far as I remember messages headers are immutable, increments cannot be
achived via nack. As part of the EventBus we re-submitted a brand new message
instead.
This thus seems harder to achieve.
Am I missing something?
> Badly formatted mailqueue causes RabbitMQMailQueue to crash
> -----------------------------------------------------------
>
> Key: JAMES-3291
> URL: https://issues.apache.org/jira/browse/JAMES-3291
> Project: James Server
> Issue Type: New Feature
> Components: Queue, rabbitmq
> Affects Versions: master, 3.5.0
> Reporter: Benoit Tellier
> Priority: Major
>
> ## Reproduction steps:
> Given a bad payload published on the mailQueue exchange
> Then the dequeuer will crash and stop any following dequeuing processing
> ## Consequences:
> This can be leveraged to knock down mail reception given only the right to
> publish messages to RabbitMQ.
> This can generate problems to users when upgrading with non-empty mailqueue
> upon MailReferenceDTO changes
> ## Alternatives
> To not be crashing, we actually need to handle the deserialization exception.
> Dropping the message would be a quick fix, but could result in data loss.
> A better alternative would be to leverage a dead-letter queue in order to
> enable to not abort processing, while keeping track of the failure, and
> allowing to resume its processing.
> ## Related issues
> We are considering improving the reliability of the distributed mailqueue
> component, and allow to drop all RabbitMQ content. To recover from such a
> situation, non-dequeued emails would be tracked using the Cassandra browsing
> projection, and requeued in a newly provisionned rabbitMQ.
> Given the ability to re-generate non - dequeued entries, dropping invalid
> rabbitMQ messages could be acceptable, as the admins will have the right
> tools to re-generate legitimate traffic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
