You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "Dondorp, Erwin" <er...@cgi.com> on 2021/04/26 10:21:33 UTC
how to prevent messages loss on startup with federation
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
RE: how to prevent messages loss on startup with federation
Posted by "Dondorp, Erwin" <er...@cgi.com>.
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) queue-federation.
The original address will then become dual-type (multicast+anycast).
With that, I would only need to re-publish these messages on the original address while on the second broker.
Erwin
-----Oorspronkelijk bericht-----
Van: Justin Bertram <jb...@apache.org>
Verzonden: maandag 26 april 2021 21:51
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.
> ...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 <er...@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 <jb...@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 <er...@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
> >
>
Re: how to prevent messages loss on startup with federation
Posted by Justin Bertram <jb...@apache.org>.
> ...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 <er...@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 <jb...@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 <er...@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
> >
>
RE: how to prevent messages loss on startup with federation
Posted by "Dondorp, Erwin" <er...@cgi.com>.
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 <jb...@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 <er...@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
>
Re: how to prevent messages loss on startup with federation
Posted by Justin Bertram <jb...@apache.org>.
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 <er...@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
>