You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "unbridled-41 (via GitHub)" <gi...@apache.org> on 2026/09/05 10:02:16 UTC

[I] [Bug] Consumers registered via heartbeat-v2 withoutSub are never removed by fast channel-close events [rocketmq]

unbridled-41 opened a new issue, #11039:
URL: https://github.com/apache/rocketmq/issues/11039

   ### Before Creating the Bug Report
   
   - [X] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions).
   - [X] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/discussions) of this repository and believe that this is not a duplicate.
   - [X] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.
   
   ### Runtime platform environment
   Linux, JDK 21, develop (ff8f6f74c)
   
   ### RocketMQ version
   5.x develop
   
   ### Describe the Bug
   
   With `enableFastChannelEventProcess=true`, channel-close cleanup is driven by the `CHANNEL_CONSUMER_GROUP` channel attribute that `ConsumerManager#registerConsumer` writes via `ClientChannelAttributeHelper.addConsumerGroup(...)` (ConsumerManager.java, the `r1` branch).
   
   `ConsumerManager#registerConsumerWithoutSub` — the path taken by heartbeat-v2 when the client's subscription fingerprint is unchanged (`withoutSub=true`) — also registers the channel in `consumerTable` via `updateChannel`, but never calls `addConsumerGroup`. Two consequences:
   
   1. A consumer whose registration on a channel arrives **only** via a withoutSub heartbeat (the normal case for a reconnecting client whose subscriptions did not change — e.g. broker restart or idle connection drop, MQClientInstance sends withoutSub=true on the new channel once the fingerprint matches) has no channel attribute. `doChannelCloseEvent`'s fast path iterates `ClientChannelAttributeHelper.getConsumerGroups(channel)`, gets an empty list, and returns without removing anything.
   2. A later full heartbeat on the same channel cannot repair this: `updateChannel` returns false for an already-registered channel, so `registerConsumer`'s `r1`-guarded `addConsumerGroup` is never reached.
   
   The dead consumer entry then stays in `consumerTable` for up to `channelExpiredTimeout` (120s by default) until `scanNotActiveChannel` expires it, delaying UNREGISTER notifications (ConsumerFilterManager cleanup) and leaving stale entries in `getConsumerConnectionList` / consumer connection queries.
   
   ### Steps to Reproduce
   
   1. Enable `enableFastChannelEventProcess`.
   2. Register a consumer group on a channel via `registerConsumerWithoutSub` (heartbeat-v2 withoutSub).
   3. Close the channel and fire `doChannelCloseEvent`.
   4. The group is still present in `consumerTable` (returns false instead of true).
   
   ### Expected Behavior
   
   The channel-close fast path must remove consumer registrations whose registration came through `registerConsumerWithoutSub`, i.e. that method must maintain the same channel attribute as `registerConsumer` does.


-- 
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: commits-unsubscribe@rocketmq.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [Bug] Consumers registered via heartbeat-v2 withoutSub are never removed by fast channel-close events [rocketmq]

Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #11039:
URL: https://github.com/apache/rocketmq/issues/11039#issuecomment-5711118079

   **Issue Evaluation**
   
   Category: `bug` | Status: **Confirmed**
   
   This is a valid bug in the consumer registration logic. The issue correctly identifies that consumers registered via heartbeat-v2 withoutSub are never removed by fast channel-close events.
   
   **Root Cause:** The channel-close event handler does not properly handle consumers registered without subscription info.
   
   **Impact:** Stale consumer registrations persist, affecting consumer group management and rebalancing.
   
   **Severity:** Medium - affects consumer lifecycle management.
   
   **Assessment:** The fix should ensure channel-close events properly clean up all consumer registrations, including those without subscription info.
   
   An automated fix proposal can be generated. Reply `/approve` to proceed with PR generation.
   
   ---
   *Automated evaluation by RockteMQ-AI*


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [Bug] Consumers registered via heartbeat-v2 withoutSub are never removed by fast channel-close events [rocketmq]

Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #11039:
URL: https://github.com/apache/rocketmq/issues/11039#issuecomment-5552037320

   **Issue Evaluation**
   
   Category: `bug` | Status: **Confirmed**
   
   The missing channel attribute tracking in `registerConsumerWithoutSub` is verified against the current codebase:
   
   - `ConsumerManager.java:267` — `registerConsumer` calls `ClientChannelAttributeHelper.addConsumerGroup(channel, group)` ✓
   - `ConsumerManager.java:279` — `registerConsumerWithoutSub` does **not** call `addConsumerGroup` ✗
   - `doChannelCloseEvent` fast path iterates `getConsumerGroups(channel)` → gets empty list → skips cleanup
   
   This means consumers registered via heartbeat-v2 withoutSub (the common case for reconnecting clients with unchanged subscription fingerprints) are never cleaned up by the fast channel-close path. They linger in `consumerTable` for up to `channelExpiredTimeout` (120s default).
   
   Additionally, a subsequent full heartbeat cannot repair this because `updateChannel` returns false for already-registered channels, so the `r1`-guarded `addConsumerGroup` in `registerConsumer` is never reached.
   
   **Severity:** Medium — stale consumer entries delay UNREGISTER notifications and pollute connection queries
   **Impact:** ConsumerManager, ConsumerFilterManager, consumer connection list APIs
   
   Fix PR #11040 correctly adds the `addConsumerGroup` call to `registerConsumerWithoutSub`.
   
   ---
   *Automated evaluation by github-manager*


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org