You could have the Bridge listening to one subscription for one node.. and sending to the other center... so everything received in one place would be send towards the other center.
If you have producers on the other center though things will be complicated..as you would send back what you received and you would by math definition feedback messages on an infinite loop. Just be careful with that part. (you could filter out feedback with an expression though). It's a bit non orthodox but it would work. On Fri, Oct 16, 2015 at 9:35 AM, Justin Bertram <jbert...@apache.com> wrote: > Just to clarify, a bridge only ever goes between two servers. The > <static-connectors> element contains all the possible destinations of the > bridge, and the bridge will select one of those based on some try/fail logic. > The bridge won't make a connection between the source and every single entry > in <static-connectors>. > > > Justin > > ----- Original Message ----- > From: "Kevin Niemann" <kevin.niem...@gmail.com> > To: users@activemq.apache.org > Sent: Friday, October 16, 2015 12:52:49 AM > Subject: Re: Artemis deployment question > > I've got the cluster working, I'm now trying to configure three or more > brokers with core bridges between each other, such that any one broker can > publish a message to a topic and it be consumed on the other two brokers > (assuming there is a subscription/listener present). > > As I mentioned, I'm using Core Bridges to communicate over a WAN. > Clustering works best in a single data center. > > E.g. > Node 1: JMS client publishes a message to topic Stock.YHOO. > Node 2: JMS client is subscribed to Stock.YHOO and receives message via > core bridge. > Node 3: JMS client is subscribed to Stock.YHOO and receives message via > core bridge. > > The example of a core bridge only includes two brokers. > > On Thu, Oct 15, 2015 at 6:22 PM, Clebert Suconic <clebert.suco...@gmail.com> > wrote: > >> Looking at your configuration, you don't need to define the Bridge... the >> cluster connection when defined will take care of that part. >> >> an easy way to do that is by using the following: >> >> >> ./artemis create /serverplace --clustered --host localhost >> ./artemis create /serverplace --clustered --host localhost --port-offset 1 >> >> >> (answer the questions through the input stream) >> >> >> >> that will be using UDP. Take a look at the example I mentioned before as >> well. >> >> >> On Thu, Oct 15, 2015 at 9:02 PM, Kevin Niemann <kevin.niem...@gmail.com> >> wrote: >> >> > Hello, >> > >> > I'm looking into an implementation of ActiveMQ Artemis at my org. I want >> > to be sure I can use a JMS client to publish to a topic on any node in >> the >> > below diagram and subscribe from any or all other nodes. >> > >> > I've not been able to prove this configuration. The bridge works between >> > two nodes, but when I add additional nodes it doesn't seem to create more >> > bridges as I would expect. >> > >> > Note that the Core Bridges will be going over the WAN, that's why 4-6 >> > aren't part of the cluster. >> > >> > See some of my broker.xml below. Let me know if you have questions. >> > [image: Inline image 1] >> > *Node 1:* >> > <queues> >> > <queue name="jms.topic.Node1"> >> > <address>jms.topic.Node1.#</address> >> > </queue> >> > </queues> >> > >> > <connectors> >> > <!-- Connector to the other node --> >> > <connector name="Node4-connector">tcp://192.168.1.5:61616 >> > </connector> >> > <connector name="Node5-connector">tcp://192.168.1.6:61616 >> > </connector> >> > <connector name="netty-connector">tcp://192.168.1.2:61616 >> > </connector> >> > </connectors> >> > >> > <bridges> >> > <bridge name="my-bridge"> >> > <queue-name>jms.topic.CHQ</queue-name> >> > <retry-interval>1000</retry-interval> >> > >> > <retry-interval-multiplier>1.0</retry-interval-multiplier> >> > <initial-connect-attempts>-1</initial-connect-attempts> >> > <reconnect-attempts>-1</reconnect-attempts> >> > >> > <failover-on-server-shutdown>false</failover-on-server-shutdown> >> > <use-duplicate-detection>true</use-duplicate-detection> >> > <confirmation-window-size>10000000</confirmation-window-size> >> > <static-connectors> >> > <connector-ref>Node4-connector</connector-ref> >> > <connector-ref>Node5-connector</connector-ref> >> > </static-connectors> >> > </bridge> >> > </bridges> >> > >> > *Node 5:* >> > >> > <queues> >> > <queue name="jms.topic.Node5"> >> > <address>jms.topic.Node5.#</address> >> > </queue> >> > </queues> >> > >> > <connectors> >> > <!-- Connector to the other node --> >> > <connector name="Node1-connector">tcp://192.168.1.2:61616 >> > </connector> >> > <connector name="Node2-connector">tcp://192.168.1.3:61616 >> > </connector> >> > <connector name="Node3-connector">tcp://192.168.1.4:61616 >> > </connector> >> > <connector name="Node4-connector">tcp://192.168.1.5:61616 >> > </connector> >> > <connector name="netty-connector">tcp://192.168.1.6:61616 >> > </connector> >> > </connectors> >> > >> > <bridges> >> > <bridge name="my-bridge"> >> > <queue-name>jms.topic.Node5</queue-name> >> > <retry-interval>1000</retry-interval> >> > <retry-interval-multiplier>1.0</retry-interval-multiplier> >> > <initial-connect-attempts>-1</initial-connect-attempts> >> > <reconnect-attempts>-1</reconnect-attempts> >> > >> > <failover-on-server-shutdown>false</failover-on-server-shutdown> >> > <use-duplicate-detection>true</use-duplicate-detection> >> > >> > <static-connectors> >> > <connector-ref>Node1-connector</connector-ref> >> > <connector-ref>Node2-connector</connector-ref> >> > <connector-ref>Node3-connector</connector-ref> >> > <connector-ref>Node4-connector</connector-ref> >> > </static-connectors> >> > </bridge> >> > </bridges> >> > >> > Thanks, >> > Kevin >> > >> >> >> >> -- >> Clebert Suconic >> -- Clebert Suconic
