[
https://issues.apache.org/jira/browse/KAFKA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235614#comment-13235614
]
Jun Rao commented on KAFKA-305:
-------------------------------
Prashant,
2. If you want to make sure that a broker is shut down, you need to call
kafkaServer.awaitShutdown after calling kafkaServer.shutdown. Overall, I don't
quite understand how the new test works. It only brought down 1 broker and yet
the comment says all brokers are down. If it is indeed that all brokers are
down, any RPC call to the broker should get a broken pipe or socket closed
exception immediately, not a sockettimeout exception. So, to really test that
the timeout works, we need to keep the broker alive and somehow delay the
response from the server. This can probably be done with a mock request handler.
> SyncProducer does not correctly timeout
> ---------------------------------------
>
> Key: KAFKA-305
> URL: https://issues.apache.org/jira/browse/KAFKA-305
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.7, 0.8
> Reporter: Prashanth Menon
> Priority: Critical
> Attachments: KAFKA-305-v1.patch
>
>
> So it turns out that using the channel in SyncProducer like we are to perform
> blocking reads will not trigger socket timeouts (though we set it) and will
> block forever which is bad. This bug identifies the issue:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4614802 and this article
> presents a potential work-around:
> http://stackoverflow.com/questions/2866557/timeout-for-socketchannel for
> workaround. The work-around is a simple solution that involves creating a
> separate ReadableByteChannel instance for timeout-enabled reads.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
