You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Kevin Niemann <ke...@gmail.com> on 2015/10/16 03:02:24 UTC
Artemis deployment question
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
Re: Artemis deployment question
Posted by Clebert Suconic <cl...@gmail.com>.
I couldn't see your picture for some reason...
But if you look at this example, it's exactly the scenario you described:
https://github.com/apache/activemq-artemis/tree/master/examples/features/clustered/clustered-topic
If you get the distribution, and go to
./examples/features/clustered/clustered-topic, you can run the example by:
mvn verify
That will create the two servers under ./target/server0 and
./target/server1 for that examples directory, and then you can play with
its config and the client
If you start the servers manually, you can start the client by using the
noServer profile (It's all on the README I believe).
mvn -PnoServer verify
The example is using UDP but you could easily combine it with the static
example (I believe that's what you tried to do) and it should work nicely.
On Thu, Oct 15, 2015 at 9:02 PM, Kevin Niemann <ke...@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
Re: Artemis deployment question
Posted by Clebert Suconic <cl...@gmail.com>.
That Clustered Bridge should take care of that part automatically. It
will create a bridge between the nodes...
I don't understand what you need I guess.
On Fri, Oct 16, 2015 at 1:52 AM, Kevin Niemann <ke...@gmail.com> wrote:
> 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 <cl...@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 <ke...@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
Re: Artemis deployment question
Posted by Kevin Niemann <ke...@gmail.com>.
Thanks Justin, that answers my question. I'd imagine that creating a
cluster over the WAN would be a bad idea?
E.g. I have a cluster of nine brokers: three brokers in Seattle, three
brokers in Shanghai and three brokers in London. Applications deployed to
each location would talk directly to their local brokers.
Would the latency cause a problem?
I've looked into Kafka:
It is generally *not* advisable to run a *single* Kafka cluster that spans
multiple datacenters over a high-latency link. This will incur very high
replication latency both for Kafka writes and ZooKeeper writes, and neither
Kafka nor ZooKeeper will remain available in all locations if the network
between locations is unavailable.
On Fri, Oct 16, 2015 at 7:19 AM, Clebert Suconic <cl...@gmail.com>
wrote:
> 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 <jb...@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" <ke...@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.suconic@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.niemann@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
>
Re: Artemis deployment question
Posted by Clebert Suconic <cl...@gmail.com>.
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 <jb...@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" <ke...@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 <cl...@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 <ke...@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
Re: Artemis deployment question
Posted by Justin Bertram <jb...@apache.com>.
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" <ke...@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 <cl...@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 <ke...@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
>
Re: Artemis deployment question
Posted by Kevin Niemann <ke...@gmail.com>.
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 <cl...@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 <ke...@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
>
Re: Artemis deployment question
Posted by Clebert Suconic <cl...@gmail.com>.
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 <ke...@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