Richard-Cranium commented on code in PR #11712:
URL: https://github.com/apache/kafka/pull/11712#discussion_r871688180
##########
streams/src/main/java/org/apache/kafka/streams/processor/internals/Tasks.java:
##########
@@ -270,6 +278,23 @@ Task task(final TaskId taskId) {
return readOnlyActiveTasks;
}
+ List<Task> orderedActiveTasks() {
+ return Collections.unmodifiableList(orderedActiveTasks);
+ }
+
+ void moveActiveTasksToTailFor(final String topologyName) {
+ final List<Task> tasksToMove = new LinkedList<>();
+ final Iterator<Task> iterator = orderedActiveTasks.iterator();
+ while (iterator.hasNext()) {
+ final Task task = iterator.next();
+ if (task.id().topologyName().equals(topologyName)) {
+ iterator.remove();
+ tasksToMove.add(task);
+ }
+ }
+ orderedActiveTasks.addAll(tasksToMove);
Review Comment:
I'll point out that attempting to handle any instance of
java.lang.VirtualMachineError in application code is a **very** bad idea. When
you see one of those, the JVM "[...] is broken or has run out of resources
necessary for it to continue operating."
I've noticed that there are places in the code base that will catch
java.lang.Throwable instances and re-throw them as java.lang.RuntimeExceptions.
That's a bad idea since you are lumping unrecoverable errors (such as those
VirtualMachineErrors) with recoverable errors.
--
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-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
