Reliable, persistent, scheduled or delayed queue processing in cluster

[Lachezar Dobrev <l....@gmail.com>]

  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

Re: Reliable, persistent, scheduled or delayed queue processing in cluster

[Tim Bain <tb...@alumni.duke.edu>]

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).

Tim
On Feb 8, 2016 5:08 AM, "Lachezar Dobrev" <l....@gmail.com> 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
>