shuan1026 opened a new pull request, #11848: URL: https://github.com/apache/ozone/pull/11848
## What changes were proposed in this pull request? `SnapshotCache.cleanup` dequeued a snapshot id on every `dbMap.compute` branch, including the keep path that skips eviction because the refcount is still positive. A concurrent last `close()` can enqueue that id after the count is read and before the dequeue; the key then stays in `dbMap` at refcount 0 and is never queued again, so later `lock()` drain checks fail. Mechanism is on HDDS-16686. This patch moves `pendingEvictionQueue.remove` onto the missing-key and successful-evict branches only. A still-referenced entry stays queued so the next cleanup pass can close it. `close()` throwing `IOException` still skips the remove, so the key remains retryable. `TestSnapshotCache#testCleanupKeepsQueuedKeyWhenStillReferenced` pins that dequeue decision: after a close-then-get, `lock()` still fails (refcount > 0), but the id stays in the queue and the following `lock()` after `close()` drains it. ## What is the link to the Apache JIRA https://issues.apache.org/jira/browse/HDDS-16686 ## How was this patch tested? - `mvn -pl :ozone-manager test -Dtest=TestSnapshotCache` in `hadoop-ozone/ozone-manager`. The new test fails on `getPendingEvictionQueue().contains(snapshotId)` after the first `lock()` without the production change, and the class passes with it (including `testStaleEvictionKeyDuringCleanup` and `testCloseFailureRetriesSnapshot`). - ci: https://github.com/shuan1026/ozone/actions/runs/40879545162 -- 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]
