[jira] [Commented] (JAMES-2896) RabbitMQ MailQueue should support delays

["Raphael Ouazana (Jira)" <se...@james.apache.org>]

    [ https://issues.apache.org/jira/browse/JAMES-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17128339#comment-17128339 ] 

Raphael Ouazana commented on JAMES-2896:
----------------------------------------

If I understand it correctly, every email in this exchange are read by some James node, but not acked until the timer expires.

 

But RabbitMQ is not supposed to retry messages if they are not acked after some times? Isn't there a risk to have the same message handled at the same time, waiting a timer to expire for each message if the delay is too big?

> RabbitMQ MailQueue should support delays
> ----------------------------------------
>
>                 Key: JAMES-2896
>                 URL: https://issues.apache.org/jira/browse/JAMES-2896
>             Project: James Server
>          Issue Type: Improvement
>          Components: Queue, rabbitmq
>            Reporter: Benoit Tellier
>            Priority: Major
>              Labels: feature
>
> MX (mail exchange) servers do rely on delays for some things like spam and abuse detection thus this is a critical capability for a mail queue component of a server aiming at being used as an MX.
> So far, RabbitMQ mail queue does not support delays. Its usage is then discouraged within an MX server (though it is perfectly suited for an MDA).
> We can relatively easily implement delays within the RabbitMQ mail queue:
>  - When a delay is specified, we save the message in the object storage,
>  fire a message on a **MailQueueDelayExchange**, and persist it on the
> MailQueueView.
>  - Each James listens on a single Queue plugged to the
> **MailQueueDelayExchange**.
>  - For each incoming message, the receiver will position a timer until
> the planned delivery (date).
>  - Upon timer completion, we ack the message of MailQueueDelayExchange,
> then we put the corresponding message in the mail RabbitMQMailQueue (no
> need to update the mailQueueView nor store again the blob).
>  - Upon connection loss, the message will be nacked and will be then
> handled by another s/consumer/jamesServer/.
> Obviously:
>  - We need synchronized clocks "best-effort" - think NTP
>  - This solution can duplicate emails upon connection loss - a local
> James needs to invalidate the entries he is waiting for upon connection loss.
>  - **flush** needs to be broadcasted so that all James servers can release the retained delayed emails into the mail queue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org