[
https://issues.apache.org/jira/browse/NIFI-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961429#comment-15961429
]
Joseph Niemiec commented on NIFI-3681:
--------------------------------------
Thinking that the follower leader method is best as ZK helps support it out of
the box with thier model. This would
* allow for election to take place instantly - based on sequence_id of the node
* allow any number of hosts to join or leave easily
* allow elections no matter how many join/leave
* prevent herd mentality by following self_seq_n - 1 and checked if one's self
became leader should the sequential node in front of it get removed (this
doesnt mean its leader.)
> Controller Service for Processor Leader Elections
> --------------------------------------------------
>
> Key: NIFI-3681
> URL: https://issues.apache.org/jira/browse/NIFI-3681
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Joseph Niemiec
> Assignee: Joseph Niemiec
>
> Today I find a need for NiFi Cluster to allow a specific set of processors to
> perform a 'LeaderElection' of sorts to allow for a single processor to
> update the process shared cluster state with assignments (both initial and
> recovery.) The CS would be responsible for joining a Zookeeper group, the
> logic itself, performing new elections should an leader die, etc...
> At its core I envision a simple API provided by the CS
> * String - whoIsLeader
> * List[String] - aliveElectors
> * Long- LastElectionEpoch ? - Not sure about this, but would it be good to
> detect if an election occurred and the leader did not change but the election
> occured. Maybe a UUID-4?
> While thinking ZK is best as Clustered NiFi already requires it would there
> be value in implementing a standalone RAFT or PAXOS that runs at the cluster
> level?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
