[
https://issues.apache.org/jira/browse/KAFKA-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696542#comment-15696542
]
ASF GitHub Bot commented on KAFKA-4245:
---------------------------------------
GitHub user ewencp opened a pull request:
https://github.com/apache/kafka/pull/2172
HOTFIX: KAFKA-4245 follow up: remove gradle wrapper, fix file headers so
Rat checks pass, and move Travis cluster file into travis directory.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ewencp/kafka hotfix-system-test-build
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/kafka/pull/2172.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 #2172
----
commit e5327ebea8c1b080ca2c1b13d47bcf834381011f
Author: Ewen Cheslack-Postava <m...@ewencp.org>
Date: 2016-11-25T19:30:33Z
HOTFIX: KAFKA-4245 follow up: remove gradle wrapper, fix file headers so
Rat checks pass, and move Travis cluster file into travis directory.
----
> 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)
