[
https://issues.apache.org/jira/browse/JAMES-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17321819#comment-17321819
]
Benoit Tellier commented on JAMES-2896:
---------------------------------------
Hello Sam,
Thanks for having a look into it!
>From your link:
{code:java}
A concrete use case for this was that we figured out that individual per
message TTL does not work as we thought it would: RabbitMQ only checks the
first message in a queue. If the first message has a 50 second TTL and the
second message has a 10 second TTL, then the second message also needs to wait
the full 50 seconds before it would actually leave the queue.
We therefore decided for a setup that was easier to reason about for us: We
decided for a queue wide message TTL.
{code}
This works with a predifined set of durations that allow you to create the
corresponding queues.
The MailQueue can be used with arbitrary delays hence I think this would make
it impractical.
Their solution is smart but requires specific conditions:
{code:java}
With this setup, we can easily change the delay as long as it is a multiple of
the wait type in the exponential back-off queue.
{code}
To be honest, when you start trying to implement advanced things (delays,
retries, content view and deletion) things becomes quickly complicated. I
wonder if we might just be better of choosing a messaging solution that better
addresses our challenges. Pulsar mostly do:
https://github.com/apache/pulsar/wiki/PIP-26:-Delayed-Message-Delivery
> 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: [email protected]
For additional commands, e-mail: [email protected]
