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.suco...@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.ritc...@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 >
