f1amingo opened a new issue, #10384: URL: https://github.com/apache/rocketmq/issues/10384
### Before Creating the Enhancement Request - [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature. ### Summary In Lite Topic exclusive subscription, when a new client preempts an lmqName, the broker only asynchronously notifies the previous owner to unsubscribe. Because cancellation is one-way and unconfirmable, the old client may keep pulling, causing double consumption and breaking the exclusive contract. This enhancement adds a server-side fallback so the broker can independently and deterministically reject pulls from an evicted client. ### Motivation - Correctness: Today's "fire-and-forget" notification cannot guarantee exclusive semantics under network jitter, client stalls, or non-conforming client implementations. - Server authority: The broker currently has no authoritative state to reject a stale consumer; it must trust client cooperation. - Robust convergence: Eviction should converge on the broker side regardless of client behavior, without requiring any client-side protocol change. ### Describe the Solution You'd Like Introduce a server-side eviction marker mechanism in the broker: - Write the marker the moment a client is evicted from an lmqName. - Check it at the Lite pull entry; reject pulls from evicted clients by reusing the existing "no message available" semantics, so no client change is needed. - Clear it through the existing subscription lifecycle paths — explicit resubscription, full subscription resync, and disconnect/timeout cleanup — so markers stay aligned with each client's current subscription set. - Self-heal lost notifications: when a heartbeat still reports an lmqName that has a marker, re-send the unsubscribe notification to drive the client toward convergence. Design principles: broker-local, in-memory, lifecycle-aligned, zero client-side impact, no new background threads. ### Describe Alternatives You've Considered - Require synchronous unsubscribe ACK from clients — breaks the zero-client-change constraint and still fails on client crashes. - Retry the unsubscribe notification with backoff — never converges for clients that don't implement the handler. - Persist eviction state — unnecessary, since broker restart forces a full client resync that naturally rebuilds authoritative state. - Pure TTL blacklist — either too short (allows double consumption) or too long (blocks legitimate resubscription); cannot align with subscription lifecycle. - Dedicated scanning thread for cleanup — redundant with existing full-sync and timeout-cleanup paths. ### Additional Context None. -- 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]
