Before Creating the Enhancement Request
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.
Before Creating the Enhancement Request
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
Describe the Solution You'd Like
Introduce a server-side eviction marker mechanism in the broker:
Design principles: broker-local, in-memory, lifecycle-aligned, zero client-side impact, no new background threads.
Describe Alternatives You've Considered
Additional Context
None.