Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: <CAKF+bsrE3eXE23Jxuwxm7eftfK3XtSuJG+CNghtFzNpem+apOQ@mail.gmail.com>
References: <CA+B0Vwx003ZMBnpWGK+hcsJSkiySm2Ou8Ce4Uks=tQ2MaLQB8A@mail.gmail.com>
 <CAKF+bsrE3eXE23Jxuwxm7eftfK3XtSuJG+CNghtFzNpem+apOQ@mail.gmail.com>
From: Bruce Ritchie <bruce.ritchie@gmail.com>
Date: Wed, 11 Jan 2017 12:07:28 -0500
Message-ID: <CA+B0VwxOPC7XLkQ6Q3d8dh9djwCDgAqmDq0fQwwyd6SmYXfr7g@mail.gmail.com>
Subject: Re: Artemis question on JMS clustered topic and high availability
To: users@activemq.apache.org
Content-Type: multipart/alternative; boundary=94eb2c1cc8e07d43480545d4a481
archived-at: Wed, 11 Jan 2017 17:08:11 -0000

--94eb2c1cc8e07d43480545d4a481
Content-Type: text/plain; charset=UTF-8

Your reply is much appreciated. So crossing master/slave is only possible
in a colocated environment? If so I think that's doable in my situation.

"what you are looking is having a copy of the topic subscription on every
node, making it a single cluster among different nodes,"

Is there an example of this I can work from? I previously was working from
the example @
https://github.com/apache/activemq-artemis/tree/1.x/examples/features/clustered/clustered-topic


Thanks!


On Wed, Jan 11, 2017 at 11:53 AM, Clebert Suconic <clebert.suconic@gmail.com
> wrote:

> when you have a topic subscription in cluster.. the message will be
> copied to every subscription on the cluster connection (or network of
> brokers)...
>
>
> When you have the same subscription among different nodes.. (that
> is... the same core-queue name on more than one node), then
> load-balancing will have a play...
>
>
> what you are looking is having a copy of the topic subscription on
> every node, making it a single cluster among different nodes, and
> that's not what you have here. You would need a backup to save the
> acks between two servers.
>
>
> you can have multiple master/slaves on your environment, and even
> cross them on a colocated environment, having a phisical server with 2
> live nodes in case of failures.
>
>
>
> Don't know if that helps?
>
> On Tue, Jan 3, 2017 at 2:30 PM, Bruce Ritchie <bruce.ritchie@gmail.com>
> wrote:
> > I've been investigating switching from a single activemq server to a
> > cluster of artemis servers on aws and I have a question on clustered jms
> > topics and high availability.
> >
> > Firstly, I like the idea that the producers/consumers can connect to any
> > node in the cluster and fail over (client side) to a different node if a
> > node goes down without loosing any messages with the understanding that
> the
> > producers may have to retry submissions.
> >
> > In my usage scenario I do not have any queues - just two jms topics.
> > Multiple producers, multiple consumers. What I've been trying to figure
> out
> > is if I can away with not having a <ha-policy>. The clustered topic
> example
> > seems to indicate that with a message-load-balancing set to STRICT that
> > it'll copy messages to other nodes in the cluster if a corresponding
> topic
> > already exists there. My understanding from reading the docs is that
> this a
> > true copy (potentially async I assume) vs something like a read-through
> > from one node to another when the message doesn't exist on the local
> node.
> > Is that correct?
> >
> > If the above is correct and the fact that I don't have a requirement to
> be
> > able to recover messages after a full cluster restart is there any reason
> > to have a ha-policy set? The only reason I can think of is to sync
> messages
> > in the topic between shutdown and restart of a node in the cluster prior
> to
> > clients reconnecting to that node so that the client(s) may not miss
> > messages (potential dup are ok in my use case). That's pretty important
> but
> > I'm not sure I have can both the clustered jms topics in a symmetrical
> > cluster and have a ha-policy (ala [master0/slave1] <-->
> [master1/slave0]).
> > Is that possible?
> >
> > Thanks!
>
>
>
> --
> Clebert Suconic
>

--94eb2c1cc8e07d43480545d4a481--