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 (Updated) (JIRA)" <ji...@apache.org> on 2012/02/03 23:49:54 UTC

[jira] [Updated] (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 updated KAFKA-48:
---------------------------

    Attachment: KAFKA-48.patch

This is a very rough draft of long poll support. It appears to work. Here are some remaining issues:
1. I need the updated request objects to properly get the new fields (min_bytes, max_wait). Currently I am just hard-coding some made-up values.
2. This patch is very specific to long poll support for fetch requests, it will require more generalization to support our other async case, namely delaying produce requests until a certain number of slaves are caught up.
3. There are still some unit test problems.
4. Code is a little rough still.

Take a look if interested, I will discuss with a few people and clean up a little more before asking for a real review.
                
> 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
>         Attachments: KAFKA-48.patch
>
>
> 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