You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Jay Kreps (JIRA)" <ji...@apache.org> on 2012/04/30 23:43:49 UTC

[jira] [Resolved] (KAFKA-48) Implement optional "long poll" support in fetch request

     [ https://issues.apache.org/jira/browse/KAFKA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kreps resolved KAFKA-48.
----------------------------

    Resolution: Fixed

Included most of Joel's comments, and fixed a few lagging unit tests (in particular refactored AutoOffsetResetTest).

Comments on the general structure of request purgatory I am going to put off until we have our second use case ready to implement--the producer acks. When we have that I am going to look at refactoring so that the "satisfaction action" is a function included with the DelayedRequest which is executed regardless of whether the request is satsified or times out. But I want to put this off until we can check it against the specifics of the second use case.
                
> 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: Jun Rao
>            Assignee: Jay Kreps
>         Attachments: KAFKA-48-v2.patch, KAFKA-48-v3.patch, KAFKA-48-v4.patch, KAFKA-48.patch, kafka-48-v3-to-v4-changes.diff
>
>
> 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