Gabriel Reid created KAFKA-4245:
-----------------------------------
Summary: 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.10.0.0, 0.9.0.0, 0.8.1
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)
