You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@samza.apache.org by "Navina Ramesh (JIRA)" <ji...@apache.org> on 2017/03/29 21:57:41 UTC

[jira] [Commented] (SAMZA-1173) Evaluate CoordinationService design and resolve unresolved questions from PR#91

    [ https://issues.apache.org/jira/browse/SAMZA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15947964#comment-15947964 ] 

Navina Ramesh commented on SAMZA-1173:
--------------------------------------

Another question:
Why does the coordinationService interface take "processorId" as an argument? That makes it very tightly coupled with the Samza's definition of processorId. 

> 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
>
> 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)