vamossagar12 commented on code in PR #13801:
URL: https://github.com/apache/kafka/pull/13801#discussion_r1273932710
##########
connect/runtime/src/main/java/org/apache/kafka/connect/storage/ConnectorOffsetBackingStore.java:
##########
@@ -279,8 +284,51 @@ public Future<Void> set(Map<ByteBuffer, ByteBuffer>
values, Callback<Void> callb
throw new IllegalStateException("At least one non-null offset
store must be provided");
}
+ boolean containsTombstones = values.containsValue(null);
+
+ // If there are tombstone offsets, then the failure to write to
secondary store will
+ // not be ignored. Also, for tombstone records, we first write to
secondary store and
+ // then to primary stores.
+ if (secondaryStore != null && containsTombstones) {
+ AtomicReference<Throwable> secondaryStoreTombstoneWriteError = new
AtomicReference<>();
+ FutureCallback<Void> secondaryWriteFuture = new FutureCallback<>();
+ secondaryStore.set(values, secondaryWriteFuture);
+ try {
+ // For EOS, there is no timeout for offset commit and it is
allowed to take as much time as needed for
+ // commits. We still need to wait because we want to fail the
offset commit for cases when
Review Comment:
Thanks for the comment. Yeah it makes sense to block for EOS in this case.
Regarding this =>
> We should return a Future to the caller that corresponds to all of the
offset flushes that we'd need to block on for an offset commit (i.e., the
existing flush that we're performing, possibly preceded by a preemptive flush
of tombstones to the secondary store).
I did spend time trying to accomplish this but was not able to do it.
Ideally I could have used something like callback chaining with
CompletableFutures but I couldn't get it it working at that time. The problem
is, if the writes to secondary stores fail for tombstone offsets, then we don't
want to proceed further. That's why I thought it might be better to keep the 2
flows separate but yeah, we do get a different Future objects in that case.
--
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
