-
Notifications
You must be signed in to change notification settings - Fork 15.4k
KAFKA-14299: Fix pause and resume with state updater #13025
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
Changes from all commits
50b03d2
6649c83
1c56e83
8d306e2
827f7ec
0846241
124fedf
9d83fe7
e030650
7673087
019de46
198461d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -200,7 +200,7 @@ public StateStore getStore(final String name) { | |
|
|
||
| @Override | ||
| public Map<TopicPartition, Long> changelogOffsets() { | ||
| throw new UnsupportedOperationException("This task is read-only"); | ||
| return task.changelogOffsets(); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I understand the code correctly, this forwarding is fine. |
||
| } | ||
|
|
||
| @Override | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1115,6 +1115,12 @@ private void removeLostActiveTasksFromStateUpdater() { | |
| } | ||
| } | ||
|
|
||
| public void signalResume() { | ||
| if (stateUpdater != null) { | ||
| stateUpdater.signalResume(); | ||
| } | ||
| } | ||
|
|
||
| /** | ||
| * Compute the offset total summed across all stores in a task. Includes offset sum for any tasks we own the | ||
| * lock for, which includes assigned and unassigned tasks we locked in {@link #tryToLockAllNonEmptyTaskDirectories()}. | ||
|
|
@@ -1532,15 +1538,38 @@ Set<TaskId> standbyTaskIds() { | |
| } | ||
|
|
||
| Map<TaskId, Task> allTasks() { | ||
| // not bothering with an unmodifiable map, since the tasks themselves are mutable, but | ||
| // if any outside code modifies the map or the tasks, it would be a severe transgression. | ||
| if (stateUpdater != null) { | ||
| final Map<TaskId, Task> ret = stateUpdater.getTasks().stream().collect(Collectors.toMap(Task::id, x -> x)); | ||
| ret.putAll(tasks.allTasksPerId()); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've changed the func name slightly in another PR, so if that PR is merged we need to do a slight rebase/conflict resolution, just FYI.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, once you merge the other one we can rebase this one. |
||
| return ret; | ||
| } else { | ||
| return tasks.allTasksPerId(); | ||
| } | ||
|
Comment on lines
+1543
to
+1549
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I could not find a test for this change. Could you add one?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
| } | ||
|
|
||
| /** | ||
| * Returns tasks owned by the stream thread. With state updater disabled, these are all tasks. With | ||
| * state updater enabled, this does not return any tasks currently owned by the state updater. | ||
| * @return | ||
| */ | ||
| Map<TaskId, Task> allOwnedTasks() { | ||
| // not bothering with an unmodifiable map, since the tasks themselves are mutable, but | ||
| // if any outside code modifies the map or the tasks, it would be a severe transgression. | ||
| return tasks.allTasksPerId(); | ||
| } | ||
|
|
||
| Set<Task> readOnlyAllTasks() { | ||
| // need to make sure the returned set is unmodifiable as it could be accessed | ||
| // by other thread than the StreamThread owning this task manager; | ||
| return Collections.unmodifiableSet(tasks.allTasks()); | ||
| // not bothering with an unmodifiable map, since the tasks themselves are mutable, but | ||
| // if any outside code modifies the map or the tasks, it would be a severe transgression. | ||
| if (stateUpdater != null) { | ||
| final HashSet<Task> ret = new HashSet<>(stateUpdater.getTasks()); | ||
| ret.addAll(tasks.allTasks()); | ||
| return Collections.unmodifiableSet(ret); | ||
| } else { | ||
| return Collections.unmodifiableSet(tasks.allTasks()); | ||
| } | ||
| } | ||
|
|
||
| Map<TaskId, Task> notPausedTasks() { | ||
|
|
||
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.
To be consistent, we should also verify here if the task already exists similar to the
else-branch.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'm wondering if this complexity is necessary, since we do not make strict ordering guarantees for paused topologies -- i.e. it's okay to still processing those tasks for a while after the
pause()call is triggered. Is it really a correctness or concurrency issue?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
PauseResumeIntegrationTestis testing precisely this (that no progress is made when a task is added in paused state). I also wasn't sure how important this property is for KSQL, but I suppose it is important enough that Jim wrote a unit test for it. I also think it makes sense to have the property, making a little progress on a paused task is unintuitive IMHO.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.
w.r.t. Bruno's comment: done
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.
While working on another PR I realized in
checkAllUpdatingTaskStateswe only try to pause tasks when the commit interval has elapsed, i.e. when we pause a named topology, its corresponding tasks may only be paused after a while, while when we resume, tasks are resumed immediately.So I think we should move the
pausinglogic out of thecheckAllUpdatingTaskStatesas well likeresuming, which would leavecheckAllUpdatingTaskStatesto just becomemaybeCheckpointUpdatingTasks. WDYT?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.
Sorry, almost missed this comment. I think this would work, but it would mean cycling through the list of all tasks in every single iteration of main state updater loop. I thought the pause code was only run after
commitMsto reduce this overhead, so I thought it makes sense. It's different for resume, because we get a resume signal from the stream thread.