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
