Matt, > Yep, sounds like the firewall constraint is going to nix the static network. Very nice to get a confirmation on that, it takes away the remaining doubt.
> it sounds like your options are to look at implementing a series of bridges That is exactly what we already started doing, and indeed with wildcards. But I'll now take a second look at Camel. thx!!! Erwin -----Oorspronkelijk bericht----- Van: Matt Pavlovich <mattr...@gmail.com> Verzonden: donderdag 20 mei 2021 19:29 Aan: users@activemq.apache.org Onderwerp: Re: question on ActiveMQ advisory messages for large cluster 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. Yep, sounds like the firewall constraint is going to nix the static network. If you must create connections in one-direction, it sounds like your options are to look at implementing a series of bridges. Check out Camel. ActiveMQ supports consuming from multiple queues and using wildcards, and composite destinations[1]. This gets you the dynamic consumer behavior without having to use advisories. ie.. consume from uri=“queue:ORDER <queue://ORDER>.>" would match all queues that start with “ORDER." You can do dynamic deploy and have process control with Camel, so that is a bonus for when endpoints turn-up or down and if you need to recycle the connections for what ever reason. [1] https://urldefense.com/v3/__https://activemq.apache.org/composite-destinations__;!!AaIhyw!9XkMezMkgcgKgeaF907ZPiLX-3tOHZOeA7hV4yS_gpMkfT6r_QF63b91-JrIaqE-$ -Matt > On May 20, 2021, at 11:42 AM, Dondorp, Erwin <erwin.dond...@cgi.com> wrote: > > Matt, > >> Have you considered a purely static network configuration? > Due to firewall constraints, we are forced to use "duplex" routing. > Static routing only seems to work one-way, thus it does not look useable to > me. > > e. > > -----Oorspronkelijk bericht----- > Van: Matt Pavlovich <mattr...@gmail.com> > Verzonden: donderdag 20 mei 2021 18:31 > Aan: users@activemq.apache.org > Onderwerp: Re: question on ActiveMQ advisory messages for large cluster > > > 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. > > Hi Erwin- > > Have you considered a purely static network configuration? > > -Matt Pavlovich > >> On May 20, 2021, at 11:12 AM, Dondorp, Erwin <erwin.dond...@cgi.com> wrote: >> >> Hello! >> >> We are using ActiveMQ in a star-network of a few hundred remote brokers on >> small computers with a more beefy central broker(set). >> Functionally, this works fine. >> Unfortunately, the network is not always stable (but this is exactly why we >> use a messaging solution). >> On network problems that affect most-or-all remote brokers, upon >> reconnection, a very large amount of advisory messages are sent between the >> nodes. >> The amount of messages seems to be quadratic with the number of brokers. >> And the number of advisory message types is high because we use unique >> destinations per remote broker, so the amount is actually cubic. >> We see millions of these messages on such occasions. >> >> Obviously, we are trying to reduce this, and looked at >> https://urldefense.com/v3/__https://activemq.apache.org/advisory-message__;!!AaIhyw!9Vw1LVPo-hNr3HyIBXw_vR7Y6Rl9ZuFTKWrblXLbRW-s0o8q8Vah2B9ZtAt9C2Qr$ >> and >> https://urldefense.com/v3/__https://activemq.apache.org/networks-of-brokers__;!!AaIhyw!9Vw1LVPo-hNr3HyIBXw_vR7Y6Rl9ZuFTKWrblXLbRW-s0o8q8Vah2B9ZtMYftVeh$ >> . >> But no obvious solution was in sight. >> >> The question: >> Most of the advisory messages are useless; they are about destinations that >> a broker does not have any consumers or producers for, but still these are >> subscribed to. >> Is there a way to reduce the subscriptions on advisory topics to only the >> interesting ones? >> >> thx, >> Erwin >
