[ https://issues.apache.org/jira/browse/KAFKA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235295#comment-13235295 ]
Prashanth Menon commented on KAFKA-305: --------------------------------------- Thanks for review, Jun. 1. Will do. 2. So that test actually exposed the issue to begin with - the initial send would fail and then hang forever when attempting to refresh the topic metadata. Regardless, I'll create a separate more direct test for timeouts. On my local machine, this test seems to be unpredictable around 30% of the time. In these cases, it seems like the ephemeral broker nodes aren't removed from ZK and bringing back up a broker after shutdown throws a "Broker already exists" exception. Is anyone else experiencing it or just me? Increasing the wait time after shutdown helps but not 100%. 3. 1,2,3 Sounds fair. I should be able to get a patch in for this by Friday. Then continue on KAFKA-49 over the weekend and get it in on Saturday or Sunday should the review go okay. Apologies for the delays :( > 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