[
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)
