Ok, that makes sense. I'll play around with things some more and see what I come up with. Thanks for the help!
On Wed, Jan 11, 2017 at 7:43 PM, Clebert Suconic <clebert.suco...@gmail.com> wrote: > 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 > > > > > > > > > >
