zhaohai666 opened a new issue, #1403: URL: https://github.com/apache/rocketmq-clients/issues/1403
### 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-clients/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq-clients/issues) and [GitHub Discussions](https://github.com/apache/rocketmq-clients/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. ### Programming Language of the Client Rust ### Runtime Platform Environment rust ### RocketMQ Version of the Client/Server 5.5.1 ### Run or Compiler Version _No response_ ### Describe the Bug The `Settings` object itself does not grow in size (consistently measured at 88 bytes). The root cause lies in the combination of three factors: the reconstruction of telemetry streams during temporary "shadow sessions," a `session_map` that only ever grows (never shrinks), and the absence of HTTP/2 keepalive. Each time the server performs a rolling deployment, the client permanently loses its long-lived connection—degrading into a pattern of one-off streams (each lasting 3–43 ms) every 30 seconds. Furthermore, the accumulation of "dead" endpoints causes persistent errors during each `Settings` report cycle, accompanied by service consumption interruptions lasting 8–50 seconds. Two additional, secondary issues exacerbate the situation: the gRPC `deadline` for receive operations does not match the documentation (resulting in 100% failure when `long_polling_timeout` is set to less than 5 seconds), and `Settings` pushed from the server are simply discarded. ### Steps to Reproduce The `Settings` object itself does not grow in size (consistently measured at 88 bytes). The root cause lies in the combination of three factors: the reconstruction of telemetry streams during temporary "shadow sessions," a `session_map` that only ever grows (never shrinks), and the absence of HTTP/2 keepalive. Each time the server performs a rolling deployment, the client permanently loses its long-lived connection—degrading into a pattern of one-off streams (each lasting 3–43 ms) every 30 seconds. Furthermore, the accumulation of "dead" endpoints causes persistent errors during each `Settings` report cycle, accompanied by service consumption interruptions lasting 8–50 seconds. Two additional, secondary issues exacerbate the situation: the gRPC `deadline` for receive operations does not match the documentation (resulting in 100% failure when `long_polling_timeout` is set to less than 5 seconds), and `Settings` pushed from the server are simply discarded. ### What Did You Expect to See? The `Settings` object itself does not grow in size (consistently measured at 88 bytes). The root cause lies in the combination of three factors: the reconstruction of telemetry streams during temporary "shadow sessions," a `session_map` that only ever grows (never shrinks), and the absence of HTTP/2 keepalive. Each time the server performs a rolling deployment, the client permanently loses its long-lived connection—degrading into a pattern of one-off streams (each lasting 3–43 ms) every 30 seconds. Furthermore, the accumulation of "dead" endpoints causes persistent errors during each `Settings` report cycle, accompanied by service consumption interruptions lasting 8–50 seconds. Two additional, secondary issues exacerbate the situation: the gRPC `deadline` for receive operations does not match the documentation (resulting in 100% failure when `long_polling_timeout` is set to less than 5 seconds), and `Settings` pushed from the server are simply discarded. ### What Did You See Instead? The `Settings` object itself does not grow in size (consistently measured at 88 bytes). The root cause lies in the combination of three factors: the reconstruction of telemetry streams during temporary "shadow sessions," a `session_map` that only ever grows (never shrinks), and the absence of HTTP/2 keepalive. Each time the server performs a rolling deployment, the client permanently loses its long-lived connection—degrading into a pattern of one-off streams (each lasting 3–43 ms) every 30 seconds. Furthermore, the accumulation of "dead" endpoints causes persistent errors during each `Settings` report cycle, accompanied by service consumption interruptions lasting 8–50 seconds. Two additional, secondary issues exacerbate the situation: the gRPC `deadline` for receive operations does not match the documentation (resulting in 100% failure when `long_polling_timeout` is set to less than 5 seconds), and `Settings` pushed from the server are simply discarded. ### Additional Context _No response_ -- 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]
