qianye1001 opened a new issue, #1382: URL: https://github.com/apache/rocketmq-clients/issues/1382
### Before Creating the Enhancement Request - [x] I have confirmed that this is an enhancement to the client's connection ownership behavior. ### Programming Language of the Client Node.js ### Summary Give each Node.js `RpcClient` its own gRPC subchannel pool, matching the Java client's default connection ownership. Currently, creating separate RocketMQ client instances does not necessarily create separate TCP connections. With the same endpoint and plaintext credentials, grpc-js can reuse its global subchannel pool across their independently constructed `MessagingServiceClient` objects. ### Motivation Each RocketMQ client has its own client ID and Telemetry session, but two such sessions can run on one physical connection. Transport-level operations such as a server GOAWAY then affect multiple logical clients together. This differs from Java, where each client creates its own `ClientManagerImpl`, `RpcClientImpl`, and Netty channel. This is expected pooling behavior in grpc-js; the requested change is to RocketMQ's use of that behavior, not to grpc-js itself. ### Reproduction On upstream master `3357f9c077bfc15caa506a6271ecdf0e288f85a0`, using the lockfile's `@grpc/[email protected]`: 1. Start a local plaintext gRPC server implementing Telemetry and Heartbeat. 2. Create two actual SDK `RpcClient` instances pointing to the same server. 3. Open a Telemetry stream on each, keeping the first stream alive while opening the second. 4. Compare the server-side `call.getPeer()` values. Both streams report the same source address and port (for example, `127.0.0.1:64702`). An assertion that the peers differ fails on the unchanged source and passes after selecting a local subchannel pool. A broker-free regression test is available [here](https://github.com/qianye1001/rocketmq-clients/blob/78168a3790e4c2c9a076c4714665d1da06cc9e30/nodejs/test/client/RpcClient.test.ts). It also verifies that Telemetry and Heartbeat still reuse the connection within each client, and that the second client's connection and stream remain usable after the first client closes. ### Describe the Solution You'd Like Pass `'grpc.use_local_subchannel_pool': 1` when constructing `MessagingServiceClient` in `nodejs/src/client/RpcClient.ts`. This scopes connection reuse to one RpcClient. It increases the number of TCP connections when multiple independent clients target the same endpoint, while retaining multiplexing within each client. ### Describe Alternatives You've Considered Keeping grpc-js's global pool uses fewer connections but preserves the cross-client coupling. Exposing a public pooling option would add configuration surface; a fixed local pool is the smaller change for aligning the default behavior with Java. ### Additional Context Reproduced on macOS arm64 with Node.js 24.19.0. No RocketMQ broker is required for the transport regression test. I found no matching Node.js connection-isolation issue or PR. Related work is distinct: - #1375 adds keepalive and transport recovery, but does not select a local subchannel pool. - #1100 / #1101 proposed optional connection sharing for Java; the PR was closed without merging. -- 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]
