[
https://issues.apache.org/jira/browse/JAMES-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872882#comment-16872882
]
Tellier Benoit commented on JAMES-2794:
---------------------------------------
https://github.com/linagora/james-project/pull/2454 solved the issue
Note that it contributed an identifier for each element in the queue
(EnqueueId) that is independent of mail name and thus solves aforementioned
issues.
> RabbitMQ Mail Queue deleted elements are dequeued
> -------------------------------------------------
>
> Key: JAMES-2794
> URL: https://issues.apache.org/jira/browse/JAMES-2794
> Project: James Server
> Issue Type: Bug
> Components: Queue, rabbitmq
> Affects Versions: master
> Reporter: Tellier Benoit
> Assignee: Tellier Benoit
> Priority: Major
> Labels: bug
>
> We expect that deleted elements not to be dequeued, which RabbitMQ MailQueue
> fails to do.
> While working on this bug solving here
> https://github.com/linagora/james-project/pull/2445 , I realized one of the
> invariants we enforced on MailQueue does not hold.
> The invariant is: "A single email is enqueued a single time in a given queue".
> That invariant is broken for instance when:
> - reprocessing an email: the name is not altered
> - Recipient RewriteTable rewrites to a distant server
> - RemoteDelivery bouncing configured with an SMTP gateway
> RabbitMQ mail queue does need to leverage a Cassandra projection in order to
> offer MailQueue manageable capabilities (clear, delete, browse, size amongst
> others). We naturally chose the mail name, used everywhere to identify an
> email in order to build this projection.
> This results in a given mail being enqueued a single time in a single queue:
> on the second enqueue, the mail will be referenced as already deleted from
> the queue and will be discarded.
> In https://github.com/linagora/james-project/pull/2445 I scratched the
> surface by enforcing the aforementioned invariants where the right approach
> is to make the RabbitMQ mail queue correctly handle multiple emails enqueue
> with the same name. Which might involve table schema changes.
> We need to assign email an EnQueueId that identifies them. This level of
> indirection allows to enqueue several time the same email.
> Migration strategy:
> ### The breaking way
> - Stop exposing James to JMAP& SMTP traffic and waits for the queue to empty
> - Deploy the newest version (will create new empty tables)
> - Re-enable traffic
> In case the upgrade isdone carelessly, some email might be lost.
> I don't think we can really be smarter here...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
