[Enhancement] Remove the dedicated NameServer probe thread pool

[qianye1001]

Description

NettyRemotingClient allocates a dedicated scanExecutor for NameServer availability probes: 4 core threads, up to 10 threads, and a queue of 32 tasks. The existing housekeeping timer submits a task per address to that pool. Each task calls getAndCreateChannel(), which waits for the Netty connection future to complete.

These probes only establish or reuse connections. Netty already provides asynchronous connection completion, so the extra worker pool and task queue are unnecessary.

Expected behavior

Initiate probes directly from the existing housekeeping timer and update the available NameServer list in connection-completion callbacks. Remove the scan executor entirely, without replacing it with another executor or timer thread.

The timer must not wait for connections or a contended channel-table lock. Pending or failed connections must not be advertised as available, and late callbacks must not restore removed addresses or overwrite newer connection results. Preserve the existing scanAvailableNameSrv switch and probe interval.

[RockteMQ-AI]

Issue Evaluation

Category: enhancement | Status: Evaluated

Feasibility: Feasible
Scope: NettyRemotingClient — NameServer probe mechanism
Compatibility: No breaking changes; internal refactoring only

This is a well-reasoned optimization. The dedicated scanExecutor (4–10 threads, queue of 32) for NameServer availability probes is redundant since Netty already handles asynchronous connection completion. Removing it simplifies the threading model and reduces resource overhead.

Key considerations for implementation:

• Connection-completion callbacks must correctly handle race conditions (late callbacks, removed addresses)
• The scanAvailableNameSrv switch and probe interval must be preserved
• Pending/failed connections must not be advertised as available

This enhancement is suitable for a PR. The author has provided clear expected behavior.

---

Automated evaluation by github-manager

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Feasibility: Feasible
Scope: remoting module — NettyRemotingClient, housekeeping timer
Compatibility: No breaking changes; internal refactoring only

The analysis is sound. The dedicated scanExecutor for NameServer probes is redundant since Netty already handles asynchronous connection completion. Removing it simplifies the thread model and eliminates an unnecessary thread pool.

Key considerations for the implementation:

• The housekeeping timer callback must not block on connection futures — use the connection-completion callback to update the available NameServer list asynchronously.
• Race conditions: if an address is removed and then a late callback fires, it must not restore the removed address. A generation counter or version check can handle this.
• The scanAvailableNameSrv switch and probe interval should be preserved as-is.

This is a clean improvement to the client's thread model.

---

Automated evaluation by github-manager