> ...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 clients and federation. On the clients' acceptor you could set autoStart=false so they couldn't automatically connect as soon as the broker is up. Then you could implement a org.apache.activemq.artemis.core.server.plugin.ActiveMQServerFederationPlugin and start the acceptor when the federation connection is done and the proper queues are created. Justin On Mon, Apr 26, 2021 at 2:33 PM Dondorp, Erwin <erwin.dond...@cgi.com> wrote: > 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 > > >
