[jira] [Commented] (KAFKA-3378) Client blocks forever if SocketChannel connects instantly

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189815#comment-15189815 ] 

ASF GitHub Bot commented on KAFKA-3378:
---------------------------------------

GitHub user llowrey opened a pull request:

    https://github.com/apache/kafka/pull/1044

    KAFKA-3378 Fix for instantly connecting SocketChannels.

    Added OP_WRITE interestOp when channel connects instantly (socketChannel.connect(address) returns true... even in non-blocking mode). This allows the SocketChannel to be ready on the next call to select(). The poll method was modified to detect this case (OP_CONNECT && OP_WRITE while not key.isConnectable()) to complete the connection setup as if the channel had not connected instantly.


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/llowrey/kafka 0.9.0

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/kafka/pull/1044.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1044
    
----
commit 79f96114e0cc8a2fdadfa6738cf4c666a8c42e96
Author: Larkin Lowrey <ll...@gmail.com>
Date:   2016-03-10T18:16:06Z

    Fix for instantly connecting SocketChannels.

----


> Client blocks forever if SocketChannel connects instantly
> ---------------------------------------------------------
>
>                 Key: KAFKA-3378
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3378
>             Project: Kafka
>          Issue Type: Bug
>          Components: clients
>    Affects Versions: 0.9.0.1
>            Reporter: Larkin Lowrey
>
> Observed that some consumers were blocked in Fetcher.listOffset() when starting many dozens of consumer threads at the same time.
> Selector.connect(...) calls SocketChannel.connect() in non-blocking mode and assumes that false is always returned and that the channel will be in the Selector's readyKeys once the connection is ready for connect completion due to the OP_CONNECT interest op.
> When connect() returns true the channel is fully connected connected and will not be included in readyKeys since only OP_CONNECT is set.
> I implemented a fix which handles the case when connect(...) returns true and verified that I no longer see stuck consumers. A git pull request will be forthcoming.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)