[
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
