[ https://issues.apache.org/jira/browse/ZOOKEEPER-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080487#comment-16080487 ]
Enrico Olivelli commented on ZOOKEEPER-2755: -------------------------------------------- [~rakeshr] thank you for taking a look. I have been running ZooKeeper server in production together with other applications which use ZK since quite some time (years). Usually these application have been designed to run in a distributed architecture but they are installed in standalone mode for customers which need a simple solution, do not need to process heavy loads and it is better to have only a single process/application to deploy and maintain. When running ZK server in the same JVM of the client application you have to ensure that ZK server has the requested amount of memory to work, no OutOfMemoryErrors, no frequent full GCs. You have to be sure that the ZK server boots cleanly as first component of the application and take into account that the boot will not be immediate. Actually there is no official API to boot a ZK server (for instance Curator TestingServer is prefixed 'Testing' and it is not made for production) An interesting issue that I have found is about ephemeral nodes and expired sessions: if you start/stop the ZK server together with the application, sessions opened from a "previous life" of the application will not expire during the "stop" time as no leader is running and so at the next boot ephemeral nodes created by the application are likely to be still present for a "little" (but unpredictable) time. > Allow to subclass ClientCnxnSocketNetty and NettyServerCnxn in order to use > Netty Local transport > ------------------------------------------------------------------------------------------------- > > Key: ZOOKEEPER-2755 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2755 > Project: ZooKeeper > Issue Type: New Feature > Components: java client, server > Affects Versions: 3.5.2 > Reporter: Enrico Olivelli > Assignee: Enrico Olivelli > > ClientCnxnSocketNetty and NettyServerCnxn use explicitly InetSocketAddress > class to work with network addresses. > We can do a little refactoring to use only SocketAddress and make it possible > to create subclasses of ClientCnxnSocketNetty and NettyServerCnxn which > leverage built-in Netty 'local' channels. > Such Netty local channels do not create real sockets and so allow a simple > ZooKeeper server + ZooKeeper client to be run on the same JVM without binding > to real TCP endpoints. > Usecases: > Ability to run concurrently on the same machine tests of projects which use > ZooKeeper (usually in unit tests the server and the client run inside the > same JVM) without dealing with random ports and in general using less network > resources > Run simplified (standalone, all processes in the same JVM) versions of > applications which need a working ZooKeeper ensemble to run. > Note: > Embedding ZooKeeper server + client on the same JVM has many risks and in > general I think we should encourage users to do so, so I in this patch I will > not provide official implementations of ClientCnxnSocketNetty and > NettyServerCnxn. There will be implementations only inside the test packages, > in order to test that most of the features are working with custom socket > factories and in particular with the 'LocalAddress' specific subclass of > SocketAddress. > Note: > the 'Local' sockets feature will be available on Netty 4 too -- This message was sent by Atlassian JIRA (v6.4.14#64029)