[
https://issues.apache.org/jira/browse/ARTEMIS-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17084722#comment-17084722
]
Francesco Nigro commented on ARTEMIS-2716:
------------------------------------------
The previous objectives could be translated, with more details, in:
# preserve compatibility at configuration level (ok to add new things, trying
hard to not deprecate anything)
# it should cover the same cases of the original quorum vote
# it should cover some additional case ie 1 pair (+ 1 witness "node" - not a
full broker)
At a lower level:
# clients shouldn't change: it means that at a lower level it will reuse the
same "gossip protocol" based on Topology propagation used now
# the mechanism used to perform the backup pairing with live (that include both
the discovery process and the synchronization with it) shouldn't change
A proposal of the next steps to be followed to get this is:
# abstract away the current quorum vote: it requires extra-care because the
logic is mixed together with the replication/clustering behaviour
# refactor it in order to separate election phase and cluster member states
# design a new generic API that should just cover the higher-level
functionalities provided by the previous implementation
# choose/discuss a possible (consensus algorithm) provider that could be used
to implement a first POC (maybe as first step to get a RI)
# implement a RI version
> Implements pluggable Quorum Vote
> --------------------------------
>
> Key: ARTEMIS-2716
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2716
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Reporter: Francesco Nigro
> Priority: Major
>
> This task aim to ideliver a new Quorum Vote mechanism for artemis with the
> objectives:
> # to make it pluggable
> # to cleanly separate the election phase and the cluster member states
> # to simplify most common setups in both amount of configuration and
> requirements (eg "witness" nodes could be implemented to support single
> master-slave pairs)
> Post-actions to help people adopt it, but need to be thought upfront:
> # a clean upgrade path for current HA replication users
> # deprecate or integrate the current HA replication into the new version
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
