[ https://issues.apache.org/jira/browse/KAFKA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237021#comment-13237021 ]
Jun Rao commented on KAFKA-305: ------------------------------- If this is indeed a ZK issue, we can probably check/wait that the ephemeral node is gone before restarting the broker. > 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, KAFKA-305-v2.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