Justin,
Thanks for the verification and suggestion.
I'm not immediately executing the suggestion, as it is a bit complicated.
Not only myself (as designer/prototyper) but so many others must
use/maintain/operate the system after me (and 24/7)...
But, I'll also investigate the (asymmetric)
> ...the queue named "federated...etc" is just one more queue on the
address, and certainly not the only one.
That makes sense. Thanks for the clarification.
This is off the top of my head, but you might be able to make this work
using the following. Define separate acceptors for your normal
Justin,
> I don't understand why send-to-dla-on-no-route won't work
The messages originate from a producer-application on the first broker.
There are consumer-applications connected to the first broker and there are
consumer-applications connected to the second broker that are all interested in
I don't understand why send-to-dla-on-no-route won't work. You say, "...the
underlying queues for federation within the multicast address are only
created after the brokers have connected." Since the queues are not there
then there will be no route so send-to-dla-on-no-route would seem to be the
Hello,
We are setting up brokers that use "federation" to move messages from the first
broker to the second.
In our case, it takes a while before the brokers have connected. This is due to
some slow network setup that we cannot control.
But the underlying queues for federation within the
