zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-2755) Allow to subclass ClientCnxnSocketNetty and NettyServerCnxn in order to use Netty Local transport
Date Mon, 17 Jul 2017 15:19:00 GMT

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

Mime
View raw message