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

["Jun Rao (Commented) (JIRA)" <ji...@apache.org>]

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

Jun Rao commented on KAFKA-48:
------------------------------

Thanks for patch v3. Some comments:

31. DelayedFetch is keyed off topic. It should be keyed off (topic, partition) since a consumer may be interested in only a subset of partitions within a topic.

32. KafkaApis: The following 3 lines are duplicated in 2 places.
      val topicData = readMessageSets(delayed.fetch.offsetInfo)
      val response = new FetchResponse(FetchRequest.CurrentVersion, delayed.fetch.correlationId, topicData)
      requestChannel.sendResponse(new RequestChannel.Response(delayed.request, new FetchResponseSend(response, ErrorMapping.NoError), -1))
Should we put them in a private method and share the code?

33. ExpiredRequestReaper.purgeExpired(): We need to decrement unsatisfied count here.

34. FetchRequest: Can we have the default constants for correlationId, clientid, etc defined and shared btw the constructor and the request builder?

35. MessageSetSend.empty is unused. Should we remove it?
                
> 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.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