You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2016/10/02 14:01:20 UTC

[jira] [Commented] (KAFKA-4245) BlockingChannel#connect hides all exceptions

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

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

GitHub user gabrielreid opened a pull request:

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

    KAFKA-4245: Don't swallow IOExceptions

    Remove swallowing of exceptions from BlockingChannel#connect.
    
    This commit also slightly reworks the handling of a
    BlockingChannel in KafkaServer to correctly handle the possibility
    of an IOException being thrown by BlockingChannel#connect().
    
    Note that I'm totally new to Scala, so any advice on anything I might
    be doing here that is unconventional or just plain wrong is 
    certainly welcome.

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

    $ git pull https://github.com/gabrielreid/kafka KAFKA-4245

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

    https://github.com/apache/kafka/pull/1948.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 #1948
    
----
commit 396a52b9f0bbca5fd438dd7e4dd108fc4e4ec911
Author: Gabriel Reid <gr...@apache.org>
Date:   2016-10-02T13:44:41Z

    KAFKA-4245 Don't swallow IOExceptions
    
    Remove swallowing of exceptions from BlockingChannel#connect.
    
    This commit also slightly reworks the handling of a
    BlockingChannel in KafkaServer to correctly handle the possibility
    of an IOException being thrown by BlockingChannel#connect().

----


> BlockingChannel#connect hides all exceptions
> --------------------------------------------
>
>                 Key: KAFKA-4245
>                 URL: https://issues.apache.org/jira/browse/KAFKA-4245
>             Project: Kafka
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 0.8.2.0, 0.9.0.0, 0.10.0.0
>            Reporter: Gabriel Reid
>
> BlockingChannel currently swallows all Throwables that occur within the connect method; it appears that this behavior was introduced somewhat inadvertently by KAFKA-1041. 
> A BlockingChannel for which connect() failed will not give any indication to the caller that connecting failed, but the first call to send() or receive() will simply throw a ClosedChannelException. This behavior gives the impression that a connection was dropped after having successfully been set up, and hides any information about what failed when the original connection was set up.
> It appears that basically all uses of BlockingChannel are implemented with the expectation that an exception will be thrown by connect() if there is an issue connecting. In short, it would make a lot more sense (and make diagnosis of issues a lot easier) if exceptions from within BlockingChannel.connect were thrown all the way up the stack.



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