[
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 <[email protected]>
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)
