[
https://issues.apache.org/jira/browse/SLING-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391397#comment-16391397
]
Robert Munteanu commented on SLING-4968:
----------------------------------------
[~marett] - do you still plan to work on this? I'd like to submit it to GSOC
> ZooKeeper based discovery mechanism
> -----------------------------------
>
> Key: SLING-4968
> URL: https://issues.apache.org/jira/browse/SLING-4968
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Timothee Maret
> Assignee: Timothee Maret
> Priority: Major
> Labels: discovery, gsoc2018
>
> 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)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
