[jira] [Commented] (SLING-4968) ZooKeeper based discovery mechanism

["Bertrand Delacretaz (JIRA)" <ji...@apache.org>]

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

Bertrand Delacretaz commented on SLING-4968:
--------------------------------------------

If needed we could add a ZooKeeper server to (a variant of) my https://github.com/bdelacretaz/docker-sling-cluster prototype to be able to test a non-embedded ZK variant.

> 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
>              Labels: discovery
>
> 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
(v6.3.4#6332)