kfaraz commented on code in PR #19091:
URL: https://github.com/apache/druid/pull/19091#discussion_r2891113835


##########
indexing-service/src/main/java/org/apache/druid/indexing/seekablestream/supervisor/SeekableStreamSupervisor.java:
##########
@@ -2669,18 +2677,50 @@ private void verifyAndMergeCheckpoints(
         sequenceCheckpoint -> {
           killTask(
               sequenceCheckpoint.lhs,
-              "Killing task[%s], as its checkpoints[%s] are not consistent 
with group checkpoints[%s]"
-              + " or latest persisted sequences in metadata store[%s].",
-              sequenceCheckpoint.lhs,
-              sequenceCheckpoint.rhs,
-              taskGroup.checkpointSequences,
-              latestOffsetsFromDb
+              "Killing task as its checkpoints are not consistent with group 
checkpoints"
+              + " or latest persisted sequences in metadata store."
           );
           taskGroup.removeTask(sequenceCheckpoint.lhs);
         }
     );
   }
 
+  /**
+   * Checks if there is another {@link TaskGroup} publishing to any of the 
partitions
+   * that are being read by the given {@param taskGroup}. If this method 
returns
+   * true, it indicates that the current taskGroup would need to wait for the
+   * older taskGroups to finish publishing before it can publish its own 
offsets.
+   */
+  private boolean isAnotherTaskGroupPublishingToPartitionsOf(TaskGroup 
taskGroup)
+  {
+    final Set<PartitionIdType> partitionsPendingPublishFromOtherGroups =
+        pendingCompletionTaskGroups
+            .values()
+            .stream()
+            .flatMap(Collection::stream)
+            .filter(group -> !group.equals(taskGroup))

Review Comment:
   Thanks for calling this out!
   
   Yeah, I didn't override the equals/hashCode on purpose since each 
`TaskGroup` object is supposed to be distinct. I will add a comment to that 
effect.
   
   Also the equality filter in this method is just a safe-side measure since 
the `taskGroup` passed into this method will always be one of the 
`activelyReadingTaskGroups` and it will be compared against 
`pendingCompletionTaskGroups`. The two sets will always be distinct except when 
the target `taskGroup` is moved from `activeReadingTaskGroups` to 
`pendingCompletionTaskGroups` while this method is in progress (which should 
not happen either since the notices are all handled by the single-threaded 
`exec`).
   
   Let me know if that makes sense or if I should update the logic or add more 
comments.



-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to