-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[fix][broker] Fix snapshot creation race causing delayed delivery bucket trim failures #26260
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
base: master
Are you sure you want to change the base?
Changes from all commits
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 |
|---|---|---|
|
|
@@ -126,6 +126,11 @@ public static record SnapshotKey(long ledgerId, long entryId) {} | |
|
|
||
| private volatile CompletableFuture<Void> trimFuture; | ||
|
|
||
| @VisibleForTesting | ||
| CompletableFuture<Void> getTrimFuture() { | ||
| return trimFuture; | ||
| } | ||
|
|
||
| public BucketDelayedDeliveryTracker(AbstractPersistentDispatcherMultipleConsumers dispatcher, | ||
| Timer timer, long tickTimeMillis, | ||
| boolean isDelayedDeliveryDeliverAtTimeStrict, | ||
|
|
@@ -918,20 +923,32 @@ private synchronized CompletableFuture<Void> asyncTrimImmutableBuckets() { | |
|
|
||
| private CompletableFuture<Void> deleteBucketSnapshot(String ledgerName, | ||
| Range<Long> range, ImmutableBucket bucket) { | ||
| return bucket.asyncDeleteBucketSnapshot(stats) | ||
| .handle((__, t) -> { | ||
| if (t != null) { | ||
| log.warn().attr("LedgerName", ledgerName) | ||
| .attr("BucketKey", bucket.bucketKey()) | ||
| .log("Failed to delete bucket snapshot"); | ||
| throw new CompletionException(t); | ||
| } | ||
| return bucket.getSnapshotCreateFuture().orElse(NULL_LONG_PROMISE) | ||
| .thenCompose(bucketId -> { | ||
| synchronized (this) { | ||
| snapshotSegmentLastIndexMap.entrySet().removeIf(entry -> entry.getValue() == bucket); | ||
| removeBucket(range); | ||
| numberDelayedMessages.addAndGet(-bucket.getNumberBucketDelayedMessages()); | ||
| Long firstLedgerId = firstActiveLedgerId(); | ||
| if (INVALID_BUCKET_ID.equals(bucketId) | ||
| || firstLedgerId == null | ||
| || range.upperEndpoint() >= firstLedgerId | ||
| || immutableBuckets.asMapOfRanges().get(range) != bucket) { | ||
| return CompletableFuture.completedFuture(null); | ||
| } | ||
| } | ||
| return null; | ||
| return bucket.asyncDeleteBucketSnapshot(stats).thenRun(() -> { | ||
|
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. The orphan eligibility is validated only before the asynchronous snapshot deletion begins. Once this synchronized block is released, the cursor may be reset or its mark‑deleted position could move backward while In such cases, the completion block only rechecks the range‑to‑bucket identity, so it may still delete bucket state even if Could we add a deletion ownership or version guard that spans the duration of the asynchronous operation, or base orphan cleanup on a monotonic physical‑ledger boundary? Please also include a test that blocks |
||
| synchronized (this) { | ||
| if (immutableBuckets.asMapOfRanges().get(range) != bucket) { | ||
| return; | ||
| } | ||
| snapshotSegmentLastIndexMap.entrySet().removeIf(entry -> entry.getValue() == bucket); | ||
| removeBucket(range); | ||
| numberDelayedMessages.addAndGet(-bucket.getNumberBucketDelayedMessages()); | ||
| } | ||
| }); | ||
| }).exceptionally(t -> { | ||
| log.warn().attr("LedgerName", ledgerName) | ||
| .attr("BucketKey", bucket.bucketKey()) | ||
| .log("Failed to delete bucket snapshot"); | ||
| throw new CompletionException(t); | ||
| }); | ||
| } | ||
|
|
||
|
|
||
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.
This ensures the global
trimFuturewaits for every selected bucket's snapshot-creation future. If any create future remains pending for an extended period,trimFuture.isDone()stays false, which prevents lateraddMessage()calls from triggering another trim/merge and also chainsclear()behind the same future.Would it be safer to skip buckets still in the CREATING state and retrigger trim when their creation finishes, rather than holding the global trim/merge gate? At minimum, it would be helpful to document the bounded-completion guarantee or add a test for a create future that never completes.