[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922139#action_12922139
 ] 

Patrick Hunt commented on ZOOKEEPER-901:
----------------------------------------

It would be great if you supported both netty/nio as part of this change, but 
it's really up to you. 

Going fwd (long term) we should covert everything over from nio to netty. It's 
not a matter of nio vs netty really - it's a matter of security. Netty provides 
encryption/auth out of the box (sorta), while we'd have to do a bunch of work 
to add this on top of our current nio. So really we're moving to netty 
primarily to get security for client & server connectivity. An added bonus is 
that netty should simplify our code (although in the short term that's def not 
the case).

Thanks!



> Redesign of QuorumCnxManager
> ----------------------------
>
>                 Key: ZOOKEEPER-901
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-901
>             Project: Zookeeper
>          Issue Type: Improvement
>          Components: leaderElection
>    Affects Versions: 3.3.1
>            Reporter: Flavio Junqueira
>            Assignee: Flavio Junqueira
>             Fix For: 3.4.0
>
>
> QuorumCnxManager manages TCP connections between ZooKeeper servers for leader 
> election in replicated mode. We have identified over time a couple of 
> deficiencies that we would like to fix. Unfortunately, fixing these issues 
> requires a little more than just generating a couple of small patches. More 
> specifically, I propose, based on previous discussions with the community, 
> that we reimplement QuorumCnxManager so that we achieve the following:
> # Establishing connections should not be a blocking operation, and perhaps 
> even more important, it shouldn't prevent the establishment of connections 
> with other servers;
> # Using a pair of threads per connection is a little messy, and we have seen 
> issues over time due to the creation and destruction of such threads. A more 
> reasonable approach is to have a single thread and a selector.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to