KAFKA-14247: Define event handler interface and events#12663
Conversation
|
cc @guozhangwang @hachikuji @dajac for review. |
|
Thanks @hachikuji and @guozhangwang - I just updated the PR. I'm settling with |
|
Thanks @philipnee , I think we can merge the PR as is since it's new interfaces and if we found anything in follow-up developments we can always come back and change them. So LGTM. |
|
Thanks @guozhangwang! Agreed, we can make incremental changes to these implementation as we make more progress. |
Documentation on the beahvior
1c7be91 to
ccb5f14
Compare
| * This class interfaces with the KafkaConsumer and the background thread. It allows the caller to enqueue events via | ||
| * the {@code add()} method and to retrieve events via the {@code poll()} method. | ||
| */ | ||
| public interface EventHandler { |
There was a problem hiding this comment.
I guess this is for the application side since we add application events and poll background events. Are we going to need something similar for the background thread as well?
There was a problem hiding this comment.
I don't think we need another handler on the background thread, what I'm thinking is to have the background thread living inside of the handler implementation, process the application events, and produce the background events.
Stubbed event handler
a45fb02 to
816b285
Compare
clean up documentation implemented poll and commitSync clean up clean up
83b6190 to
f5b25e6
Compare
| } | ||
| } | ||
|
|
||
| maybeSendFetches(); // send new fetches |
There was a problem hiding this comment.
I would think this would be handled by the background thread.
There was a problem hiding this comment.
the intention was to enqueue a fetch event, I think we still want the poll loop to drive the fetching, right? Maybe a better naming is needed. enqueueFetchEvent() perhaps?
There was a problem hiding this comment.
Thanks, @hachikuji - removed this line per your comment.
| import java.util.concurrent.TimeoutException; | ||
|
|
||
| /** | ||
| * This is the prototype of the consumer that uses the {@link EventHandler} to process application events. |
There was a problem hiding this comment.
I think the main thing this doc should mention is that all network IO will be done in a background thread instead of being partially driven by the application calling poll(). Also, perhaps it would be helpful to link to the wiki so that people can understand a little better?
hachikuji
left a comment
There was a problem hiding this comment.
Thanks, LGTM. Hopefully this is the beginning of the end of the single-threaded consumer.
Adds skeleton of the background thread. 1-pager: https://cwiki.apache.org/confluence/display/KAFKA/Proposal%3A+Consumer+Threading+Model+Refactor Continuation of #12663 Reviewers: Guozhang Wang <guozhang@apache.org>, Kirk True <kirk@mustardgrain.com>, John Roesler <vvcephei@apache.org>
Add some initial interfaces to kick off https://cwiki.apache.org/confluence/display/KAFKA/Proposal%3A+Consumer+Threading+Model+Refactor. We introduce an `EventHandler` interface and a new consumer implementation which demonstrates how it will be used. Subsequent PRs will continue to flesh out the implementation. Reviewers: Guozhang Wang wangguoz@gmail.com, Jason Gustafson <jason@confluent.io>
…2672) Adds skeleton of the background thread. 1-pager: https://cwiki.apache.org/confluence/display/KAFKA/Proposal%3A+Consumer+Threading+Model+Refactor Continuation of apache#12663 Reviewers: Guozhang Wang <guozhang@apache.org>, Kirk True <kirk@mustardgrain.com>, John Roesler <vvcephei@apache.org>
Add some initial interfaces to kick off https://cwiki.apache.org/confluence/display/KAFKA/Proposal%3A+Consumer+Threading+Model+Refactor. We introduce an `EventHandler` interface and a new consumer implementation which demonstrates how it will be used. Subsequent PRs will continue to flesh out the implementation. Reviewers: Guozhang Wang wangguoz@gmail.com, Jason Gustafson <jason@confluent.io>
…#30) Add some initial interfaces to kick off https://cwiki.apache.org/confluence/display/KAFKA/Proposal%3A+Consumer+Threading+Model+Refactor. We introduce an `EventHandler` interface and a new consumer implementation which demonstrates how it will be used. Subsequent PRs will continue to flesh out the implementation. Reviewers: Guozhang Wang wangguoz@gmail.com, Jason Gustafson <jason@confluent.io> Co-authored-by: Philip Nee <pnee@confluent.io>
…2672) Adds skeleton of the background thread. 1-pager: https://cwiki.apache.org/confluence/display/KAFKA/Proposal%3A+Consumer+Threading+Model+Refactor Continuation of apache#12663 Reviewers: Guozhang Wang <guozhang@apache.org>, Kirk True <kirk@mustardgrain.com>, John Roesler <vvcephei@apache.org>
…2672) (#76) Adds skeleton of the background thread. 1-pager: https://cwiki.apache.org/confluence/display/KAFKA/Proposal%3A+Consumer+Threading+Model+Refactor Continuation of apache#12663 Reviewers: Guozhang Wang <guozhang@apache.org>, Kirk True <kirk@mustardgrain.com>, John Roesler <vvcephei@apache.org> Co-authored-by: Philip Nee <pnee@confluent.io>
https://cwiki.apache.org/confluence/display/KAFKA/Proposal%3A+Consumer+Threading+Model+Refactor
In the subsequent PRs, I'll add a backgroundThread inside of the eventHandler to actually consume the events.
*Unit tests
Committer Checklist (excluded from commit message)