[Enhancement] Share consumption threads for Proxy internal clients

[qianye1001]

Motivation

Reduce the number of consumption threads used by Proxy internal clients by allowing them to share a consumption executor. System-message syncers currently create PushConsumers with dedicated consumption pools, and callers cannot supply a shared executor.

Proposed change

• Allow DefaultMQPushConsumer to accept an externally owned ExecutorService, including a virtual-thread executor supplied by applications running on JDK 21 or later.
• Wire a Proxy-owned executor through the internal system-message consumers. Keep consumer groups, subscriptions and offsets unchanged.
• Initialize the Proxy executor from ProxyConfig: core size = available processors, maximum size = twice available processors, queue capacity = 10000, and discard-oldest rejection policy.
• Use the injected executor directly and leave its shutdown to the caller. Keep ordinary consumers' existing behavior unchanged; discard handling belongs to the Proxy policy.
• Document that silently discarding consumption tasks can retain cached messages and pin offsets. Proxy should use the existing broadcast failure-result processing, which does not retry failed consumption.

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Feasibility: Feasible
Scope: module/proxy — Proxy internal system-message consumers, DefaultMQPushConsumer executor wiring
Compatibility: No breaking changes; existing consumer behavior is preserved when no external executor is supplied.

The proposal is well-scoped and addresses a real resource overhead: each system-message syncer currently allocates its own consumption thread pool. Sharing a single executor across Proxy-internal consumers reduces thread count and allows virtual-thread adoption on JDK 21+.

Key design points look sound:

• Externally owned ExecutorService on DefaultMQPushConsumer — clean separation of lifecycle
• ProxyConfig-driven pool sizing (core=processors, max=2×processors, queue=10000, discard-oldest) — reasonable defaults
• Independent consumer shutdown without closing shared executor — correct ownership semantics
• Discard-oldest policy with broadcast failure-result processing — avoids silent offset pinning

One consideration: the discard-oldest policy should be documented clearly, as silently dropping consumption tasks can retain cached messages and pin offsets if the broadcast failure path doesn't advance the offset. The issue body already acknowledges this — worth calling out in the Javadoc for the new executor-acceptance API.

An automated fix proposal can be generated if the community confirms the approach. Reply /approve to proceed with PR generation.

---

Automated evaluation by @RockteMQ-AI