Networks of brokers with only dynamically included destinations will only
forward messages when a consumer is present; otherwise, the messages will
stay on the broker to which they were published (BrokerA, in your example)
until a consumer connects to another broker in the network. But if you do
on
Thanks, gtully!
Is our implementation for #1 correct? The assumption is by disabling removal
of inactive virtual destination queues, we effectively make them static
queues the moment they are created. So, assuming a producer publishes to
"topic://virtualTopics.mytopic" on BrokerA, if BrokerB has
q
#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
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 pro
