I would be against us bringing in something that makes a nasty barrier for
entry for existing users.Think about the current situation with classic and
artemis where one of the biggest issues has been that a user cannot simply take
his/her configuration and just update the broker to the new version, theres
quite some minefield to migrate. And probably alot of the reason why still a
large part of community is still on classic.If we ended up coming up with some
system that starts from scratch and makes it that maybe not all is implemented
we will basically be making that chasm worse.We should be making this as easy
as possible for existing users / admins to just upgrade. User Community needs
to come first here.Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: nigro_franz <nigro....@gmail.com> Date:
11/04/2020 18:42 (GMT+00:00) To: dev@activemq.apache.org Subject: Re: Re:
[DISCUSSION] New Quorum vote pluggable implementation 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 adiscussion on slack to collect some
ideas & soft/hard requirements in orderto decide a roadmap: ATM I'm very
conflicted how much we should leverage onsome of the mechanisms what we
currently have (Activation(s), Topologypropagation etc etc) abstracting it away
into a more generic API or justdesigning a new thing from scratch and then
trying to make the currentbehaviour to fit into it to help migration or to let
existing users to notbe forced to adopt the new one until it wil meet their
needs.Regardless which direction to take one of my "best to have" is
theconvergence between shared-store and replication ha into a sigle
solutionwith 2 "flavours": for what HA has been done until now is just matter
ofkeep integrity and the right ownership of the journal (considering the
factthat with Ceph/GlusterFS the sync replication is provided at
file-systemlevel and with the current "software replication" is up to the
broker toperform it).It looks to me that things like FileLockNodeManager or the
JdbcNodeManagerare just 2 possible building blocks to provide the functionality
that allowto detect a loss in the journal ownership and could be used as
buildingblocks to implement (the shared store flavour of) the new API to manage
thelive-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
theservice: if anyone has specific concern or any idea why it shouldn't be
agood 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
