You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "guozhangwang (via GitHub)" <gi...@apache.org> on 2023/02/22 22:42:38 UTC

[GitHub] [kafka] guozhangwang commented on pull request #13265: Prototype consumer stubs

guozhangwang commented on PR #13265:
URL: https://github.com/apache/kafka/pull/13265#issuecomment-1440933102

   Thanks @philipnee , I left a comment to just give my 2c regarding your question 1) above.
   
   For your question 2), I think we should prefer to be consistent with the current guarantees if it's already stated in the public APIs unless there's good rationale to change it (in which case we'd need very vocally communicate it as a breaking change in the release). For example:
   
   1) We documented that rebalance listener callbacks are only related to `subscribe` scenarios, and would only be triggered within `poll()`, and only at which time the assignment could be changed.
   2) We also documented that the async commit listener callbacks are only triggered within `poll()`.
   3) In our javadocs, the CommitFailedException would only be thrown from the `commitSync` functions.
   
   Putting all those together, I think it means `poll()` call should drain the queues since if there's any events requiring any callbacks to be triggered, they should be triggered in that call; 
   
   For `commitSync`, technically it would need to wait for the corresponding commit response event, but since there's only a single queue, it means we would still need to keep polling that queue until the event is received.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org