> Now, the backup process does start processing msgs right away...
What evidence do you have of that?
> ...the ActiveMQ-client needs 2 “Trying reconnection attempts”, 1-minute
apart, before it stabilizes after the failover and is once again usable.
The log snippets you provided show a
Hi Justin,
I’m working with John Lilley on getting an ActiveMQ HA configuration
operational. Our current HA config is replication with master and slave
instances and with static connections, and it seems to be working, except that
the ActiveMQ-client is taking over 1 minute to
To be clear, the recommendation always is to conduct sufficient research to
find the "right" solution for your specific use-case. Since use-cases come
in all kinds of different shapes and sizes there is no one size fits all.
In short, take any recommendation, especially on the Internet, with a
Justin,
I don’t *think* that a single broker which is restarted by K8S will meet our
needs. Depending on where the replacement pod is created, this can take longer
than our RPC timeouts, which default to one minute. I’m hoping we’ll find a
solution where failover happens within a few
> I don’t see any branch of github for 5.19, so I am guessing the Java 11
branches are done. Is that correct?
What exactly do you mean by "done"? Both 5.17.x and 5.18.x had releases in
October.
> how long will 5.17 be supported?
What exactly do you mean by "supported"? As always, support from
I don’t see any branch of github for 5.19, so I am guessing the Java 11
branches are done. Is that correct?
Related question: how long will 5.17 be supported?
Douglas Whitfield
This e-mail may contain information that is privileged or confidential. If you
are not the intended recipient,
Hi Justin,
Thanks for response. Regarding below comment
" It's certainly true that LVQ + clustering is not a good fit (as noted in the
docs [1]), but it's not clear why you're clustering in the first place or why
you're not using an actual HA configuration."
1. As par of using LVQ, are we
