activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Reliable, persistent, scheduled or delayed queue processing in cluster
Date Sat, 13 Feb 2016 09:52:49 GMT
I don't believe the JMS spec provides a mechanism for guaranteed
once-and-only-once delivery, nor how you'd provide such a guarantee in any
system.  Consider what happens when you're in the middle of processing
message A when the consuming process crashes.  A hasn't been acknowledged
as successfully processed, so you have two choices when the consumer
restarts: redeliver the message (at-least-once semantics, potentially
resulting in it being processed twice) or don't (at-least-once semantics,
potentially resulting in it being processed zero times).

Otherwise your requirements (except cancellation) can all be met by any JMS
2.0 implementation (which Artemis is) or any JMS 1.0 implementation that
provides an extension for scheduled delivery (as ActiveMQ and others do).

On Feb 8, 2016 5:08 AM, "Lachezar Dobrev" <> wrote:

>   Hello users,
>   For a project I'm currently working on we decided to use a cluster of
> application instances with embedded Artemis services connected via explicit
> tunnels.
>   A requirement for the application functions expects us to be able to
> handle certain events (from user interface layer), and in response
> schedule/delay a task to be executed on any node in the cluster. The task
> is supposed to be reliable even if the node that emits the task goes down.
> Also if all nodes go down and then any of them gets brought up again, then
> tasks that were missed should be executed. It's also a strict expectation,
> that a task will only be executed once on any node, and not on more than
> one concurrently.
>   An ability to 'cancel' pending tasks would be very useful, although this
> can be performed in the task itself.
>   For the time being the Artemis service is used using JMS interfaces only.
>   Is such use case solvable using Artemis?
>   Lachezar

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message