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 these messages. Therefore the address on the first broker also has the additional subscription-queues for this. (and the address on the second broker only has a couple of regular subscriber-queues). So, the queue named "federated...etc" is just one more queue on the address, and certainly not the only one. And that makes send-to-dla-on-no-route unusable for this.
And additional problem would be that it would be a bit complicated to (1) get the messages from a DLA queue back into the original stream, and (2) get all of that in the original sequence so that none of the clients on the second broker would have to do that. Erwin -----Oorspronkelijk bericht----- Van: Justin Bertram <jbert...@apache.org> Verzonden: maandag 26 april 2021 17:53 Aan: users@activemq.apache.org Onderwerp: Re: how to prevent messages loss on startup with federation EXTERNAL SENDER: Do not click any links or open any attachments unless you trust the sender and know the content is safe. EXPÉDITEUR EXTERNE: Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous ayez l'assurance que le contenu provient d'une source sûre. 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 appropriate solution. Justin On Mon, Apr 26, 2021 at 5:22 AM Dondorp, Erwin <erwin.dond...@cgi.com> wrote: > 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 multicast address > are only created after the brokers have connected. > This causes some message loss as the clients happily produce messages > on an address with no underlying queues. > For any next startup, the queue will still be there. But many times, > for us, the startup is a "first" startup. > > Is there a way to prevent this message loss? > > We already tried to pre-define the "federation.xxx" queues with the > exact same names. But that leads to a broken system in which the > federation channel does not even work anymore. > There may be any number of local consumers on the first node, so any > trick using send-to-dla-on-no-route is not so useable. > > Thx! > Erwin >
