kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jun Rao (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-48) Implement optional "long poll" support in fetch request
Date Mon, 02 Jan 2012 17:20:30 GMT

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

Jun Rao commented on KAFKA-48:


Sorry for the late response. I am not sure that I understand your proposal. 

a. Why do we need a local socket? It seems that the same thing can be achieved by just turning
on the write_interesting bit in the socket key corresponding to a client request.

b. It's not clear to me how you correlate a queued client request with the corresponding client
> Implement optional "long poll" support in fetch request
> -------------------------------------------------------
>                 Key: KAFKA-48
>                 URL: https://issues.apache.org/jira/browse/KAFKA-48
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Alan Cabrera
>            Assignee: Jay Kreps
> Currently, the fetch request is non-blocking. If there is nothing on the broker for the
consumer to retrieve, the broker simply returns an empty set to the consumer. This can be
inefficient, if you want to ensure low-latency because you keep polling over and over. We
should make a blocking version of the fetch request so that the fetch request is not returned
until the broker has at least one message for the fetcher or some timeout passes.

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


View raw message