[
https://issues.apache.org/jira/browse/KAFKA-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227277#comment-13227277
]
Prashanth Menon edited comment on KAFKA-49 at 3/12/12 8:33 PM:
---------------------------------------------------------------
A few more concerns popped up as a result of making the send in syncproducer
blocking.
1. Edit: So it turns out that using the channel in SyncProducer like we are to
perform reads won't trigger socket timeouts though we set it and will block
infinitely which is bad news(check
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4614802 and
http://stackoverflow.com/questions/2866557/timeout-for-socketchannel for
workaround). The latter post has a simple solution that involves creating a
separate ReadableByteChannel instance for timeout-enabled reads.
2. It is conceivable that a broker listed in the replica set
/brokers/topics/[topic]/partitions/[partition]/replicas is offline or shutdown
which means their ephemeral entries are missing in ZK. A problem then arises
when an active broker attempts to pull metadata and node information for topics
these brokers host since AdminUtils assumes any broker in AR or ISR must have
paths/info in ZK /brokers/ids/[brokerId], but since they don't an
NoNodeException is thrown. A corner case for sure, but something that should
probably be fixed.
was (Author: prashanth.menon):
A few more concerns popped up as a result of making the send in
syncproducer blocking.
1. Edit: So it turns out that using the channel in SyncProducer like we are to
perform reads won't trigger socket timeouts though we set it and will block
infinitely which is bad news(check
http://stackoverflow.com/questions/2866557/timeout-for-socketchannel and
http://technfun.wordpress.com/2009/01/29/networking-in-java-non-blocking-nio-blocking-nio-and-io/).
Both posts have a fix for it which I suggest we incorporate (separate JIRA);
it comes down to having separate readable and writtable channel instances based
off the same socket.
2. It is conceivable that a broker listed in the replica set
/brokers/topics/[topic]/partitions/[partition]/replicas is offline or shutdown
which means their ephemeral entries are missing in ZK. A problem then arises
when an active broker attempts to pull metadata and node information for topics
these brokers host since AdminUtils assumes any broker in AR or ISR must have
paths/info in ZK /brokers/ids/[brokerId], but since they don't an
NoNodeException is thrown. A corner case for sure, but something that should
probably be fixed.
> Add acknowledgement to the produce request.
> -------------------------------------------
>
> Key: KAFKA-49
> URL: https://issues.apache.org/jira/browse/KAFKA-49
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Jun Rao
> Assignee: Prashanth Menon
> Fix For: 0.8
>
> Attachments: KAFKA-49-v1.patch
>
>
> Currently, the produce request doesn't get acknowledged. We need to have a
> broker send a response to the producer and have the producer wait for the
> response before sending the next request.
--
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
