[
https://issues.apache.org/jira/browse/KAFKA-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705893#comment-15705893
]
ASF GitHub Bot commented on KAFKA-4245:
---------------------------------------
Github user ewencp closed the pull request at:
https://github.com/apache/kafka/pull/2172
> 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)
