You are using AWS. Do you have the storage disk? or is it transient?
What I have been suggesting to cloud user is to just monitor their system, and have the system restarting itself in case of a failure. That is the best scenario you can get since the infra-structure would give you the needed HA. If you don't, you will need to setup a backup/live pair for each system. The only difference is that you can do that with just 2 boxes... Box1: LiveA and BackupB Box2: LiveB and BackupA That's a possible example / solution. We have a colocated topology that was developed for wildfly or embedded systems, but I would recommend you keeping it as simple as possible... either have the infra-structure restarting itself if you have the storage... or have a backup pair like I'm suggesting here. I feel like I missed answering something here.. let me know if I am... On Wed, Jan 11, 2017 at 12:07 PM, Bruce Ritchie <bruce.ritc...@gmail.com> wrote: > 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 >> -- Clebert Suconic
