[
https://issues.apache.org/jira/browse/KAFKA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140450#comment-13140450
]
Taylor Gautier commented on KAFKA-48:
-------------------------------------
I can see how it would be reasonable to do the first approach. It does limit
one use case I was considering, which is to allow the consumer to decide in
which order to fetch the topics after the poll is triggered, however, this can
be done at request time when the topics are requested.
As you say, the response is 100% compatible, it's just the request that
changes. Therefore it would make sense I think to go ahead and make a new
request type that doesn't yet exist and then the current fetch request remains
the same on the wire and the behavior of it is just a degenerate case of this
new use case with delay and bytes set to 0.
I think you might consider how useful is it to wait for user specified
time/bytes? It will add a lot of complexity to your implementation, and
frankly if I have just the ability to do a multi-fetch that will wait until it
has something has arrived and send me whatever it has at the current moment
that will be good enough. It should also probably provide a simple timeout
that will respond with nothing if the timeout expires.
I think that's a huge win and you might consider -- is that good enough?
For me - I would prefer to get the simple thing in the short term and work on
the harder thing in the long-term rather than waiting a longer time for the
harder thing to be done.
> 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-socket-server-refactor-draft.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
