[
https://issues.apache.org/jira/browse/ZOOKEEPER-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14130830#comment-14130830
]
Reed Wanderman-Milne commented on ZOOKEEPER-900:
------------------------------------------------
Hi,
I'm wondering if there's any progress on this JIRA. I'm running into an issue
similar to that of ZOOKEEPER-1678, which can be solved by fixing this. If no
one is working on it, I'd be happy to take a stab at it.
[~vishalmlst]'s patch added a timeout for connections to other peers, but it
still seems appears that only one connection can be processed at a time.
Additionally, in connectOne(long), a lock on the QuorumPeer is held, preventing
other threads from accessing it. Both this issues seem to contribute to
ZOOKEEPER-1678. [~vishalmlst] suggested in an earlier comment to move the
socket operations to SenderWorker and RecvWorker, which would prevent socket
operations from blocking other connections.
Let me know what your thoughts are. Thanks!
> FLE implementation should be improved to use non-blocking sockets
> -----------------------------------------------------------------
>
> Key: ZOOKEEPER-900
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-900
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Vishal Kher
> Assignee: Vishal Kher
> Priority: Critical
> Fix For: 3.5.1
>
> Attachments: ZOOKEEPER-900.patch, ZOOKEEPER-900.patch1,
> ZOOKEEPER-900.patch2
>
>
> From earlier email exchanges:
> 1. Blocking connects and accepts:
> a) The first problem is in manager.toSend(). This invokes connectOne(), which
> does a blocking connect. While testing, I changed the code so that
> connectOne() starts a new thread called AsyncConnct(). AsyncConnect.run()
> does a socketChannel.connect(). After starting AsyncConnect, connectOne
> starts a timer. connectOne continues with normal operations if the connection
> is established before the timer expires, otherwise, when the timer expires it
> interrupts AsyncConnect() thread and returns. In this way, I can have an
> upper bound on the amount of time we need to wait for connect to succeed. Of
> course, this was a quick fix for my testing. Ideally, we should use Selector
> to do non-blocking connects/accepts. I am planning to do that later once we
> at least have a quick fix for the problem and consensus from others for the
> real fix (this problem is big blocker for us). Note that it is OK to do
> blocking IO in SenderWorker and RecvWorker threads since they block IO to the
> respective peer.
> b) The blocking IO problem is not just restricted to connectOne(), but also
> in receiveConnection(). The Listener thread calls receiveConnection() for
> each incoming connection request. receiveConnection does blocking IO to get
> peer's info (s.read(msgBuffer)). Worse, it invokes connectOne() back to the
> peer that had sent the connection request. All of this is happening from the
> Listener. In short, if a peer fails after initiating a connection, the
> Listener thread won't be able to accept connections from other peers, because
> it would be stuck in read() or connetOne(). Also the code has an inherent
> cycle. initiateConnection() and receiveConnection() will have to be very
> carefully synchronized otherwise, we could run into deadlocks. This code is
> going to be difficult to maintain/modify.
> Also see: https://issues.apache.org/jira/browse/ZOOKEEPER-822
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
