[ 
https://issues.apache.org/jira/browse/KAFKA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233119#comment-13233119
 ] 

Prashanth Menon commented on KAFKA-305:
---------------------------------------

Hi all, I've attached a patch.  Some notes:

- New class called BlockingChannel that has timeouts enabled.
- SyncProducer uses BlockingChannel instead of creating its own SocketChannel
- Re-introducsed testZKSendWithDeadBroker which passes now.

I'd like to get feedback on this.  It's simple and may be reused on the 
consumer side.  When I think about it, it would be nice to combine 
SimpleConsumer and SyncProducer into one generic "SimpleClient" since the 
functionality is effectively the same.

I'd also like to benchmark this against a pure NIO implementation where we can 
use selectors to enabled timeout functionality.  It'll be more complex and will 
require minor adjustment to BoundedByteBuffer and BoundedByteBufferSend but it 
may be worth it.
                
> 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
>
> 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

        

Reply via email to