messere1 opened a new pull request, #11355:
URL: https://github.com/apache/rocketmq/pull/11355
## What changed
- `ExclusiveEvictionTombstones` now stamps every tombstone with its eviction
time (backing store changed from a key set to `ConcurrentMap<String, Long>`),
and gained `removeExpired(ttlMillis)`
- `LiteSubscriptionRegistryImpl.cleanupExpiredSubscriptions` discards
tombstones older than the check timeout, on the same horizon it already uses to
expire subscriptions
- re-adding a tombstone after a later re-eviction refreshes its stamp,
restarting the guard window (semantics unchanged otherwise:
`contains`/`remove`/`removeAllOf`/`removeStale` keep their contracts)
## Why
A tombstone only needs to survive until the evicted client's next full
subscription sync, which any live client performs well within the subscription
expiry window (`liteSubscriptionCheckTimeoutMills`, default 3 minutes). But
when the eviction takes the client's **last** liteTopic, its `LiteSubscription`
is dropped from `client2Subscription` immediately — and if that client then
terminates without sending `COMPLETE_REMOVE`, nothing ever clears its
tombstones:
- the sync-driven removals (`remove` on re-claim, `removeStale` on full
sync) need requests that never arrive;
- the expiry cleaner only walks `client2Subscription`, so it cannot see the
evicted clientId anymore.
The tombstone set therefore grows without bound under exclusive-mode client
churn (every takeover evicts the previous holder; terminated losers leak one
`clientId$lmqName` key each) until broker restart. This is the same
reachability gap as #11352 for the channel entry, on the adjacent per-client
structure of the same eviction branch.
Expiring on the subscription timeout only affects clients the broker already
considers gone: a live client either syncs (clearing its tombstones via
`removeStale`) or lets its subscription expire (which clears them via
`removeCompleteSubscription` → `removeAllOf`) within the window, so the guard
against stale pulls from a just-evicted client is kept for at least as long as
the client's own subscription would survive.
## Impact
The change is local to the exclusive-eviction tombstone bookkeeping of the
lite subscription registry. Non-exclusive groups never get tombstones;
eviction, re-claim, full-sync re-notify and client-removal flows keep their
behavior.
Fixes #11354
## Validation
- `mvn -pl broker
-Dtest='LiteSubscriptionRegistryImplTest,ExclusiveEvictionTombstonesTest'
-Djacoco.skip=true test`
- 54 tests, 0 failures, 0 errors (49 pre-existing + 3 new)
- `testExclusiveEviction_TombstoneExpiredForClientThatNeverSyncsAgain`
fails on the pristine branch (`java.lang.AssertionError` — the tombstone
survives the expiry sweep with no subscription entry left to sweep) and passes
with the fix
- `testExclusiveEviction_FreshTombstoneSurvivesExpirySweep` guards the
boundary: a tombstone younger than the check timeout is kept by the cleaner
(passes on the pristine branch as well)
- `ExclusiveEvictionTombstonesTest#testRemoveExpired` covers the TTL unit
semantics (fresh kept / aged removed)
- `mvn -pl broker -Dtest='org.apache.rocketmq.broker.lite.*Test'
-Djacoco.skip=true test`
- 122 tests, 0 failures (whole lite package regression)
- `mvn -pl broker
-Dtest='AckMessageProcessorTest,LiteManagerProcessorTest,LiteSubscriptionCtlProcessorTest'
-Djacoco.skip=true test`
- 39 tests, 0 failures (lite ack/manager/ctl processor regression)
- `mvn -pl broker
-Dtest='PopLiteMessageProcessorEventLossTest,PopLiteMessageProcessorTest'
-Djacoco.skip=true test`
- 24 tests, 0 failures (lite pop processor regression, incl. the
tombstone-checked pull path)
- `mvn -pl broker checkstyle:check
-Dcheckstyle.config.location=style/rmq_checkstyle.xml`
- 0 violations
JaCoCo is skipped locally because the repository's JaCoCo 0.8.5 agent does
not support Java 17 class files.
--
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]
