[
https://issues.apache.org/jira/browse/ZOOKEEPER-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089702#comment-16089702
]
ASF GitHub Bot commented on ZOOKEEPER-2755:
-------------------------------------------
Github user ivankelly commented on the issue:
https://github.com/apache/zookeeper/pull/227
@eolivelli
Sorry for taking so long to respond, I was out of town.
The commit message explains what the patch is doing, but not why. The
reason I'm pushing back a lot on this, is that I think it adds indirection and
complexity, and I don't see what the benefit is over simply binding to 0.
The patch claims to abstract away the communication channel between server
and client. But this is a broken abstraction as there are many places where the
application expects this to be an IPv4 channel. To get around this you've
created a static helper class, but internally this either forces a cast to
InetSocketAddress or provides a stub, which seems hacky.
How are you using zookeeper in single node mode? Is it only as a metadata
store for bk? I'm reluctant to approve a patch that adds significant complexity
without addressing a widely desirable usecase.
> 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)
