You are still bound to connect retries and TTLs. So I would say that a good reaction time would be 30s. You can decrease that but I am not sure I recommend it.
It's up to you thought. If I was implementing my own system I would prefer the cloud infra since you are AWS. I believe that's what most cloud systems do on their back end when you hire Messaging for instance. Just trying to help. On Wed, Jan 11, 2017 at 5:28 PM Bruce Ritchie <bruce.ritc...@gmail.com> wrote: > 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 > > > > >
