digyear opened a new pull request, #16454: URL: https://github.com/apache/dubbo/pull/16454
## What is the purpose of the change Add server-side `max-connection-age` support for the Triple protocol, aligned with the standard gRPC capability ([gRFC A9: Server-Side Connection Management](https://github.com/grpc/proposal/blob/master/A9-server-side-conn-mgt.md)). HTTP/2 multiplexes all requests over a single long-lived connection, so a Triple consumer stays pinned to the same provider instance forever — even after new instances are scaled up or traffic should be rebalanced. gRPC solves this with `maxConnectionAge` / `maxConnectionAgeGrace`: when a connection exceeds the configured age, the server sends an advisory GOAWAY (`NO_ERROR`, `last-stream-id = MAX_INT`) so in-flight requests keep running while clients migrate to a new connection (and get redistributed by the load balancer), then closes the connection after the grace period. Triple currently has no equivalent: there is no way for a Triple server to proactively rotate long-lived connections. This PR adds it, disabled by default. ## Brief changelog - **`TripleConfig`**: add `maxConnectionAge` (ms, default `-1` = disabled) and `maxConnectionAgeGrace` (ms, default `10000`) with validation, following the existing field conventions (`getXxxOrDefault()`); matching `TripleBuilder` methods in dubbo-config-api. - **`TripleServerConnectionHandler`**: on `channelActive`, if `maxConnectionAge > 0`, schedule a one-shot task on the channel's EventLoop with **±10% jitter** (same as grpc-java) to avoid mass simultaneous reconnections when many connections are established at the same time. On expiry: 1. send the advisory GOAWAY via the existing `GracefulShutdown.sendGoAwayFrame` (reuses the production code path — in-flight streams are unaffected); 2. after the grace period, initiate close through `ctx.channel().close()` so the request traverses this handler's `close()` override and runs the existing graceful-shutdown sequence (final GOAWAY + PING) instead of an abrupt disconnect; 3. pending tasks are cancelled on `channelInactive` (no leaks when the client disconnects first). - **`TripleHttp2Protocol`**: pass the config into the handler on both server pipeline paths (direct h2 and h1-upgrade); raise the codec's `gracefulShutdownTimeoutMillis` to at least the configured grace so Netty's built-in backstop never fires before it. Usage: ```yaml dubbo: protocol: name: tri triple: max-connection-age: 3600000 # rotate connections after ~1h max-connection-age-grace: 10000 # let in-flight requests finish ``` ## Verifying this change New tests (all passing): - `TripleServerConnectionHandlerTest` — EmbeddedChannel with virtual clock: advisory GOAWAY (`NO_ERROR` + `extraStreamIds=MAX_INT`) fires within the jitter window and never before it; disabled by default (24h, no frames); tasks cancelled on `channelInactive`; graceful-shutdown sequence (final GOAWAY + PING) initiated after the grace period. - `TripleServerConnectionHandlerConcurrencyTest` — real NIO server/client, 100 connections sharing 2 EventLoop threads: concurrent rotation of all connections; client disconnects racing age expiry (random delays within ±20% of the window); server-side `close()` racing pending age tasks; 5 rounds of connection churn under `ResourceLeakDetector.PARANOID` with zero leak reports. - `TripleConfigTest` / `TripleBuilderTest` — defaults, validation and builder wiring. Regression: full test suites of `dubbo-rpc-triple` (492), `dubbo-common` (1169) and `dubbo-config-api` (695) pass locally. Note for reviewers: with the current consumer-side GOAWAY handling (#16344), each rotation costs one request failure window on the consumer, so this feature is best paired with the graceful consumer migration in #16345. This PR is independent and safe to merge on its own (default: disabled). ## Does this pull request potentially affect one of the following parts - [ ] Dependencies (does it add or upgrade a dependency) - [x] The public API (new optional `TripleConfig` fields; default values keep behavior unchanged) - [ ] The persistence format of the configurations - [x] The default values of configurations (new fields only; existing defaults untouched) - [ ] The serialization protocol - [ ] The compatibility with previous versions ## Documentation - Does this pull request introduce a new feature? **yes** - If yes, how is the feature documented? **JavaDoc on the new `TripleConfig` fields** (website docs can follow after merge) -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
