If you know in advance which destinations are local-only and which ones might need to be routed across the network of brokers, it's possible to dynamically include or exclude destinations whose names match certain patterns. See activemq.apache.org/networks-of-brokers.html for more details.
You can also go to a fully statically routed network of brokers to eliminate the overhead of advisory messages; details are at the same link. But are you sure you need to? Are you sure this isn't a premature optimization that will have a cost (more complicated broker configs) but no measurable benefit? Do you have an indication that either of those is necessary from a performance standpoint? What's driving your original question? On Oct 28, 2015 3:32 AM, "Jako" <i...@simone.pro> wrote: > Hi, > we have a lot of brokers all attached to a central H broker in a hub and > spoke topology. > Clients will connect to the external brokers A, B, C, D, E and F. > > > I have a working setup like this with more or less 350 external brokers. > Through logs and jmx I see that all the queues are 'present' on all the > clients. > Actually the clients of different brokers have to speak to each other in > rare occasions. > > So, is there a way to lighten the clients and remove the existence of the > whole network queues from their awareness? In exclusion of the queues of > the > same broker clients. > You could say, and how could clients of different nodes communicate? > I hope that there is a mean to achieve routing as the ip protocol: when the > broker A receives a message for a non local queue, it should forward it to > the H broker; H will have all the queues in the network, that's expected. > > Is this possible, or am I talking nonsense? > > Thank you for your help > Simone > > < > http://activemq.2283324.n4.nabble.com/file/n4703434/broker_networks_09.gif > > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Hub-and-spoke-network-topology-tp4703434.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
