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://activemq.apache.org/composite-destinations -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 >
