[
https://issues.apache.org/jira/browse/KAFKA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140467#comment-13140467
]
Jay Kreps commented on KAFKA-48:
--------------------------------
Hi Taylor,
Could you give a little more detail on your use case for ordering the fetches?
I think you have a use case I haven't thought of, but I don't know if I
understand it. Is your motivation some kind of quality of service over the
topics?
As you say, this would definitely be a new request type for compatibility, and
we would probably try to deprecate the old format over the next few releases as
we can get clients updated.
Your point about complexity is valid. I think for our usage since we use kafka
very heavily the pain of grandfathering in new APIs is the hardest part, and
the socket server refactoring is next, so I was thinking the difficulty of
implementing a few internal data structures is not too bad. I suppose it
depends on if I work out a concrete plan there or not. If the best we can do is
iterate over the full set of watchers it may not be worth 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: 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
