[
https://issues.apache.org/jira/browse/NIFI-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022277#comment-16022277
]
ASF GitHub Bot commented on NIFI-3681:
--------------------------------------
Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/1800
couple of quick thoughts.
- we'll need to get all the version numbers aligned with whatever nifi
version this would be committed into. Currently that would be 1.3.0-SNAPSHOT.
- It would probably be a good idea to have the notion of
'nifi-leaderelection-api' which is not about zookeeper but rather just generic
election/tracking of a leader for a given thing (a partition?) Then there would
be zookeeper based implementations of those. Processors then can leverage the
api for their code but users can select whichever types of services exist
(zookeeper being the obvious initial example). The structure appears already
in place for this other than the current naming and perhaps the API referencing
zookeeper. Thoughts?
- It would be good to have a processor which leverages this or some docs
that go along with it to show suggested usage.
> 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)
