[
https://issues.apache.org/jira/browse/ZOOKEEPER-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089952#comment-16089952
]
ASF GitHub Bot commented on ZOOKEEPER-2755:
-------------------------------------------
Github user eolivelli commented on the issue:
https://github.com/apache/zookeeper/pull/227
@ivankelly thank you for your time
> 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.
I will rewrite the message and explain better.
Benefits for tests: I agree with you that binding to 0 will solve the
problem of running multiple tests on the same machine, this change will only
add the ability to work without opening real ports.
For production: With in-vm transport you will not open ZK clientPort to the
world, which in turn will be a security risk. If you open the clientPort, even
only on loopback you need to configure ZK security at ZK level or for instance
iptables
> you've created a static helper class
Yes, unfortunately there is no automatic way to map local addresses to
InetAddress. I have included the "mapToLocalAddress" method which is used only
in tests in order to define a standard practice to map LocalAddress. This patch
does not introduce an official CnxnFactory for Local transport, but there is a
need to define how it should be used. Maybe it would be better to add the
official CnxnFactory
> How are you using zookeeper in single node mode? Is it only as a metadata
store for bk?
Yes, I am using it to run BookKeeper + Bookie inside the same JVM. I am
using primary BK as write-ahead-log for replicated states machines.
For every application now I need to implement a BookKeeper based WAL +
local disk WAL, when BookKeeper is really good even in local mode.
I really would like to abstract the metadata-store and bookie discovery in
BK to not use ZK but I think this will be the work in the next year, actually
(4.5 release) we are focusing the efforts on other aspects.
I have implemented Local Transport in BK too. On BookKeeper I had the same
security problem because BK 4.4 did not have "public" security support at all
(in 4.5 we have it with SSL + SASL + ZK ACLs)
> 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)
