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

Sam commented on JAMES-2896:
----------------------------

Hi Benoit,

Thank you for your answer

 

Yes, Apache Pulsar can be the best option, because I think the implementation 
with cassandra could give more problems, and RabbitMQ needs those tricks for 
this

> 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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to