Hi Enrico, thanks for your response, sorry for the late reply. Would you mind sharing some details of your upcoming implementation, do you think it will cover our use case of using it for an embedded Zookeeper instance for a production system? If yes, we'll continue to use our own implementation until this becomes available in Zookeeper, do you have an ETA?
Best regards, Matthias Matthias Amberg Developer Office: ++41 511 11 64 unblu inc. - Kernserstrasse 17 - 6060 Sarnen - Switzerland unblu makes websites personal http://www.unblu.com Please consider the environment before printing this email. This e-mail contains including its attachments confidential protected information by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. Diese E-Mail einschließlich Ihrer Anhänge enthält vertrauliche rechtlich geschützte Informationen. Wenn Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail. Das unbefugte Kopieren oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. On 27 September 2016 at 12:40, Enrico Olivelli <[email protected]> wrote: > Hi Matthias, > I am working on a proposal on this topic. My idea is to use local netty > features. > I will share some code. > Beware that this usage of zookeeper is to be adopted only if needed. My > case is for instance to run unit tests without a real network. > Maybe you should consider to abstract your zookkeper access layer > > Enrico > > Il mar 27 set 2016, 11:07 Matthias Amberg <[email protected]> ha > scritto: > > > Dear Zookeeper developers, > > > > I have a feature request for allowing an embedded Zookeeper be run and > > connected to without using any system networking stack. All > > client-server communications would be handled internally of a single > > runtime. > > We at Unblu offer our product as a cloud service (orchestrated by > > Zookeeper) as well as an on-premises installable product. > > In the latter scenario we use a single embedded version of Zookeeper to > > orchestrate all the different embedded Version. > > This setup allows us to use the same mechanisms for service discovery and > > synchronization, whether we run in a distributed cloud setup or > > a single on-premises node. > > > > For this use case we have implemented versions of ServerCnxn, > > ServerCnxnFactory and ClientCnxnSocket that handle client-server > > connections internally without > > using any server networking stack. > > > > I would very much love to commit a patch that implements this feature or > > open a jira issue to discuss this further, if there is interest from the > > Zookeeper community for such a feature. > > > > We think this feature offers several advantages over running Zookeeper > > locally or embedded via a networking stack: > > - less system resource usage (no need for additional networking overhead > in > > what could be systems that already have a high load of networking IO) > > - simpler configuration and potentially better security: no need to > > configure any ports and network addresses, firewalls, loopback interfaces > > etc. (Our software runs in banking environments where security > constraints > > often makes it > > difficult to (even) have loopback connections) > > - simpler Continuous Integration: Different Test Runs of our builds > > constantly interfere with each other due to ports being already in use > and > > so forth. > > > > Additionally as this feature simply would be an extension to the current > > code base that wouldn't even be instantiated in the traditional server > > setup there would be almost no interference with the current code base > and > > hence no threat > > to Zookeeper stability in traditional setups. > > > > It would be great if you could provide your thoughts and feedback on this > > and whether this is a welcome feature, in which case I would create a > Jira > > Issue for further discussion and patch submission. > > > > Best regards, > > > > Matthias Amberg > > Developer > > Office: ++41 511 11 64 > > > > unblu inc. - Kernserstrasse 17 - 6060 Sarnen - Switzerland > > > > unblu makes websites personal http://www.unblu.com > > > -- > > > -- Enrico Olivelli >
