[SLING-4968] ZooKeeper based discovery mechanism

• Type: New Feature
• Status: In Progress
• Priority: Major
• Resolution: Unresolved
• Component/s: Extensions
• Labels: discovery gsoc2018
• Assignee: Unassigned
• Reporter: Timothee Maret
• Created: 25/Aug/15 15:26
• Updated: 08/Mar/18 20:30

Description

As described in SLING-2939, an embedded ZK still is not optimal since
1. Still uses System.exit statements in its code
2. Requires Netty server dependencies (Sling ships Jetty)

• extra dependencies to manage / embed
• most probably requires to run on a new port

However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation.

Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state.

This issue covers the implementation of the Sling discovery API based on ZK deployed in a dedicated infrastructure (not embedded)

Issue Links

• relates to: SLING-2939 3rd-party based implementation of discovery.api