[
https://issues.apache.org/jira/browse/SAMZA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16012928#comment-16012928
]
Boris Shkolnik commented on SAMZA-1173:
---------------------------------------
The terminology is not defined yet.
We need to revisit this facility in general.
I think we need to have the following coordination utilities:
1. LeaderElection
2. Latch
3. JobModelPublishing utility (including read, write and notifications)
They all should accept groupId parameter and may
Some questions to resolve:
- do they have a separate connections to the ZK.
- do they work as a single pack of utilities (init and configed together).
- do they support reset/cleaup.
- separate register facility for each util.
> Evaluate CoordinationService design and resolve unresolved questions from
> PR#91
> -------------------------------------------------------------------------------
>
> Key: SAMZA-1173
> URL: https://issues.apache.org/jira/browse/SAMZA-1173
> Project: Samza
> Issue Type: Bug
> Reporter: Navina Ramesh
> Assignee: Boris Shkolnik
> Priority: Critical
> Fix For: 0.14.0
>
>
> This JIRA is to address the shortcomings of the coordination service as it
> stands today. We had some unresolved questions in the PR
> [#91|https://github.com/apache/samza/pull/91]. There is also lack of clarity
> on the requirements for this interface and the use-cases for it. These need
> to be documented and discussed in a SEP.
> Here are the open questions on this interface:
> 1. reset() method - what is purpose of this method?
> 2. Need for the CoordinationService abstraction:
> bq. if there isn't any implementation for these method , can we please remove
> them until we have a solid reason to add it? From what I understand, this
> pluggable service doesn't enforce the user to use both leaderElector and
> latch implementations. So, in such a case, adding "start" to initialize
> certain environment doesn't seem correct. Will it be initialized with respect
> to leader elector or processor? LeaderElector and Latch are their own
> interfaces, anyway. What is the need to put them together in a
> "CoordinationService" abstraction? Perhaps, @xinyuiscool can help you answer
> that question
> 3. Cancelling leader election - Elaborate on why this is a required
> feature/use-case for this api
> bq. @xinyuiscool what does "cancelling" a leader election mean when you are
> within the context of "onBecomeLeader" ? Once a leader is chosen, you don't
> have to cancel it. You simply need to add every one trying to become a leader
> as a follower. Am I misunderstanding in your comment?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
