[HELIX-134] HelixManager zk session expiry/gc handling

• Type: Task
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Sprint: Sprint #4 10/2 - 10/16
• Assignee: Zhen Zhang
• Reporter: Zhen Zhang
• Created: 21/Jun/13 20:54
• Updated: 13/Sep/21 19:09
• Resolved: 13/Sep/21 19:09

Description

current helix manager is not handling zk session expiry (caused by long gc) reliably especially in case of frequent long gc's

Sub-Tasks

• separate HelixManager implementation for participant, controller, and distributed controller: Resolved
• Take care of consecutive handleNewSession() and session expiry during handleNewSession(): Resolved
• HelixManager#isLeader() should compare both instanceName and sessionId: Resolved
• handleNewSession() should wait on all left-over tasks to be cancelled successfully before start new session: Resolved
• Proper handling exception thrown by handleNewSessionAsParticipant() when an instance already exists: Open
• Flapping detection: Resolved
• Design and implement new api's for new HelixManager implementation: Resolved
• Add stress test by simulating gc and network partition for the new HelixManager implementation: Open
• Need to double check the logic to prevent 2 controllers to control the same cluster: Resolved
• Race condition between FINALIZE callbacks and Zk Callbacks: Resolved
• race condition in ZkHelixManager.handleNewSession(): Resolved
• ZkHelixManager.handleNewSession() can happen when a liveinstance already exists: Resolved
• StateModel stateTransitionMethod() and rest() are not synchronized on the partition: Open
• ZkHelixManager.handleNewSession() and ZkHelixManager.disconnect() need to be sync'ed: Open
• Possible race condition in ZkHelixManager.disconnect() during zk session expiry: Open
• ZkHelixManager.isLeader() should check session id in addition to instance name: Resolved