Thanks for the response. The paired LiveA/BackupB + LiveB/BackupA is what I was wondering out with the JMS clustered topic. I'd like to not rely on infrastructure to restart because of the latency that involves - I'd like to keep any hiccups to < 1 sec if possible.
On Wed, Jan 11, 2017 at 1:46 PM, Clebert Suconic <clebert.suco...@gmail.com> wrote: > 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 >
