activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Virtual destination subscription durability and message recovery
Date Wed, 15 Nov 2017 13:36:37 GMT
#2 is a problem - when the name of the subscription queue will be unknown.
If you know the names in advance then statically creating the destinations
will work.

You could go down the plugin route and implement/manage a shared
retroactive queue SRQ

Intercept send to the virtual topic to forward a copy to the SRQ and set an
appropriate expiry.
Intercept ack to the SRQ to ignore any remote standard ack; on expiry the
ack will have the broker context.
Intercept subscribe to the virtual topic to use a composite destination to
add SRQ to the subscription.

The down side is that a repeated connect/disconnect would get duplicates
from the SRQ. A failover client would suppress but they would generally
need to be handled and ignored.

It would be a nice feature. Essentially SRQ is some sort of time bounded
queue. A more general bounded queue would be better (bounded on size,
memory or time) but for your use case maybe the plugin is the way to go.

On Tue, 14 Nov 2017 at 00:02 Devlin <> wrote:

> We've performed extensive testing with virtual destinations on 5.11 network
> of brokers, it works well with two exceptions:
> #1 - subscription durability when consumers go offline,
> #2 - producers publishing before consumers register their subscription
> We manage to get around #1 by configuring producers to publish messages
> using PERSISTENT delivery mode, then we disabled cleanup of inactive
> virtual
> queues using wildcard destination policies. Now, when consumer who
> previously created a virtual queue subscription go offline, newly-published
> messages are retained on those queues until they are consumed, or expire;
> that's good.
> But #2 has proved challenging; we thought about using retroactive recovery
> policies, but after reading the documentation we discovered it's not
> reliable in broker networks. We're not sure how to proceed; unless there's
> a
> way to retain messages in memory, or on disk, reliably for short periods of
> time (basically recovery policy) and for an unknown number of durable
> consumers, I suspect there is no solution to this problem.
> --
> Sent from:

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