Thanks for all the feedbacks: I see this is an hot topic for sure :) In the next week I will start putting some idea in a shared doc and open a discussion on slack to collect some ideas & soft/hard requirements in order to decide a roadmap: ATM I'm very conflicted how much we should leverage on some of the mechanisms what we currently have (Activation(s), Topology propagation etc etc) abstracting it away into a more generic API or just designing a new thing from scratch and then trying to make the current behaviour to fit into it to help migration or to let existing users to not be forced to adopt the new one until it wil meet their needs.
Regardless which direction to take one of my "best to have" is the convergence between shared-store and replication ha into a sigle solution with 2 "flavours": for what HA has been done until now is just matter of keep integrity and the right ownership of the journal (considering the fact that with Ceph/GlusterFS the sync replication is provided at file-system level and with the current "software replication" is up to the broker to perform it). It looks to me that things like FileLockNodeManager or the JdbcNodeManager are just 2 possible building blocks to provide the functionality that allow to detect a loss in the journal ownership and could be used as building blocks to implement (the shared store flavour of) the new API to manage the live-backup(s) states. Just thinking loud; another thing that could be a nice thing to have (looking at kafka at this, although they allow it with a finer granularity) is the multiple-backups synchronization to increase availability of the service: if anyone has specific concern or any idea why it shouldn't be a good idea, feel free to share it. Happy easter and enjoy the longer week-end -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
