-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KAFKA-17439: Make polling for new records an explicit action/event in the new consumer #17035
Merged
Merged
Changes from all commits
Commits
Show all changes
27 commits
Select commit
Hold shift + click to select a range
e984638
KAFKA-17439: Make polling for new records an explicit action/event in…
kirktrue b6af23b
Merge remote-tracking branch 'origin/trunk' into KAFKA-17439-poll-exp…
kirktrue 335c249
Minor tweaks to FetchEvent documentation.
kirktrue 2abd6a4
Update FetchRequestManager.java
kirktrue 45bc8c0
Added unit tests to exercise poll, request-then-poll, and duplicate r…
kirktrue 7265404
Updated FetchEvent to CreateFetchRequestsEvent and catching errors fr…
kirktrue 5449549
Fixed spacing issue that checkstyle wasn't happy with
kirktrue f7a5940
Merge branch 'trunk' into KAFKA-17439-poll-explicitly
kirktrue 7acf732
Update KafkaConsumerTest.java
kirktrue 7cda968
Merge branch 'trunk' into KAFKA-17439-poll-explicitly
kirktrue de2c961
Update AsyncKafkaConsumer so that prefetch requests don't block
kirktrue a0beb14
Including fix for test that uses add() instead of addAndGet()
kirktrue af96038
Added requestGenerated back that somehow was removed
kirktrue 09e951e
No longer need to wait for FETCH RPC in test since fetches don't happ…
kirktrue fbd147c
Testing that Future.get() throws a specific exception type
kirktrue 4c7c1bf
Fixed spotless complaints
kirktrue 3aed5e7
Merge branch 'trunk' into KAFKA-17439-poll-explicitly
kirktrue b097ebe
Update AsyncKafkaConsumer.java
kirktrue 62ccaa6
Merge branch 'trunk' into KAFKA-17439-poll-explicitly
kirktrue 01b5d7a
Reducing diff noise
kirktrue aae7e97
Updated test to check that CreateFetchRequests event uses addAndGet
kirktrue b942a46
Merge branch 'trunk' into KAFKA-17439-poll-explicitly
kirktrue 63abc91
Updates to suppress exceptions for pre-fetch and handle pollOnClose()
kirktrue a98e8b0
Updates to let pre-fetch be asynchronous
kirktrue d6e2241
Tweak to comment
kirktrue 1e832e0
Merge branch 'trunk' into KAFKA-17439-poll-explicitly
kirktrue 4071849
Updated comments for sendPrefetches to correctly reflect implementation
kirktrue File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
33 changes: 33 additions & 0 deletions
33
...ain/java/org/apache/kafka/clients/consumer/internals/events/CreateFetchRequestsEvent.java
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,33 @@ | ||
/* | ||
* Licensed to the Apache Software Foundation (ASF) under one or more | ||
* contributor license agreements. See the NOTICE file distributed with | ||
* this work for additional information regarding copyright ownership. | ||
* The ASF licenses this file to You under the Apache License, Version 2.0 | ||
* (the "License"); you may not use this file except in compliance with | ||
* the License. You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, software | ||
* distributed under the License is distributed on an "AS IS" BASIS, | ||
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
* See the License for the specific language governing permissions and | ||
* limitations under the License. | ||
*/ | ||
package org.apache.kafka.clients.consumer.internals.events; | ||
|
||
import org.apache.kafka.clients.consumer.Consumer; | ||
import org.apache.kafka.clients.consumer.internals.FetchRequestManager; | ||
|
||
/** | ||
* {@code CreateFetchRequestsEvent} signals that the {@link Consumer} wants to issue fetch requests to the nodes | ||
* for the partitions to which the consumer is currently subscribed. The event is completed when the | ||
* {@link FetchRequestManager} has finished <em>creating</em> (i.e. not enqueuing, sending, or receiving) | ||
* fetch requests (if any) to send to the broker nodes. | ||
*/ | ||
public class CreateFetchRequestsEvent extends CompletableApplicationEvent<Void> { | ||
|
||
public CreateFetchRequestsEvent(final long deadlineMs) { | ||
super(Type.CREATE_FETCH_REQUESTS, deadlineMs); | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The actual poll now happens in here (addAndGet that will complete when the background has had one run, called fetchMgr.poll), so should the log line on ln 1538 "Polling for fetches with timeout..." be right before this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're not polling for the incoming responses in
sendFetches()
, just enqueuing the outgoing requests. This mimics theClassicKafkaConsumer
in that the requests are enqueued in itssendFetches()
but then toward the bottom ofpollForFetches()
client.poll()
is invoked to wait for the results of the fetch requests.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well the
sendFetches
blocks until theCreateFetchRequestsEvent
completes, and that only happens on fetchMgr.pollkafka/clients/src/main/java/org/apache/kafka/clients/consumer/internals/FetchRequestManager.java
Line 115 in aae7e97
So when the
sendFetches
completes we did poll the manager right? (and depending on time, maybe we did poll the client.poll too, which happens in the background right after polling all managers). That's why the log for "Polling for fetches" made sense to me before thesendFetches
, but am I missing another poll happening after the log line maybe? (where it is now)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The two
ConsumerDelegate
implementations work differently:AsyncKafkaConsumer
:FetchRequestManager.poll()
will complete the event'sFuture
on the background thread before it exits, i.e. before the thread starts the network I/O. Completing theFuture
starts the application thread racing toward logging that message and the background thread racing toward starting network I/O. I'll admit—I haven't dug through the code to surmise the relative costs of each thread's work before either cross their respective finish lines to win.ClassicKafkaConsumer
:Fetcher.sendFetchesInternal()
callsConsumerNetworkClient.send()
to enqueue the request, but then it callsNetworkClient.wakeup()
. Since the sameConsumerNetworkClient
instance used by the consumer is also used byAbstractCoordinator.HeartbeatThread
, it's technically possible that the heartbeat thread'srun()
method could start network I/O when it callsNetworkClient.pollNoWakeup()
. Granted, that's a race that the application thread is much more likely to win given that the heartbeat thread runs much less frequently.Here are some points to consider:
TRACE
, which I assume is very rare for users to enable.Given the above, I'm of the opinion that it's an exercise in hair splitting to alter the logging. However, I could also just change it which would have been way less effort than researching, thinking, and composing this response 🤣
If we leave the log line as it is, what would the effect be for the user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I surely didn't intend for you to put up that long response he he, sorry. It's not about the log line per-se, it's about the alignment on where the poll happens. The classic consumer logs "Polling for records", then calls
client.poll
. vs us here we dosendFetches
(which triggers the client.poll async in the background thread because it blocks until we poll the fetch manager), then log "Polling for fetches...".That's the diff I saw and just wanted to understand/align on where the poll happens: once we trigger
sendFetches
(blocking), the client.poll will happen in the background anytime, not controlled by the app thread. Agreed? If so I'm ok with leaving the log unchanged, understanding it could come out after the client.poll happened.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed—the background thread is going to move from calling each of the
RequestManager
’spoll()
method toNetworkClient.poll()
method without the intervention of the application thread.Thanks!