sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Munteanu (JIRA)" <>
Subject [jira] [Commented] (SLING-4968) ZooKeeper based discovery mechanism
Date Thu, 08 Mar 2018 15:33:00 GMT


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:
>             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

View raw message