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

• Type: Bug
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Fix Version/s: 0.14.0
• Assignee: Boris Shkolnik
• Reporter: Navina Ramesh
• Created: 28/Mar/17 22:57
• Updated: 30/Aug/17 00:50
• Resolved: 30/Aug/17 00:50

Description

This JIRA is to address the shortcomings of the coordination service as it stands today. We had some unresolved questions in the PR #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:

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

@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?

Issue Links

• depends upon: SAMZA-1201 Zk path setup for leader elector and barrier should be separated
• depends upon: SAMZA-1164 Add capability to cancel in LeaderElection
• is depended upon by: SAMZA-1064 Standalone Samza with Zookeeper for Coordination
• relates to: SAMZA-1175 Removing CoordinationUtils from JobCoordinationFactory interface
• links to: GitHub Pull Request #262

Sub-Tasks

• Remove dependency of debounce timer from the CoordinationUtils: Resolved