qiyongqiang opened a new issue, #3509: URL: https://github.com/apache/dubbo-go/issues/3509
## Describe the bug On the Dubbo/Getty consumer side, when `session.WritePkg` succeeds but `response.Done` never fires, `Client.Request` returns `errClientReadTimeout` **without** removing the session from the connection pool. `selectSession()` still randomly picks that half-dead TCP connection for later requests, so a single bad session can cause repeated ~request-timeout failures (often clustered on one consumer pod) until heartbeat eventually removes it (typically after multiple missed heartbeats). This was observed in production: consumer-side read timeout while the provider RPC completed quickly (`cost=0ms SUCCESS`), consistent with a half-dead / stuck connection rather than a slow business handler. ## Expected behavior On client read timeout for a two-way request: 1. Immediately `RemovePendingResponse` for the request ID (avoid late response matching a stale waiter) 2. `removeSession` + `Close` the session used for that request (do **not** close the whole `Client`) 3. Prefer skipping already-`IsClosed()` sessions in `selectSession` ## Related - `remoting/getty/getty_client.go` `Request()` timeout branch currently only returns the error - `RemovePendingResponse` is already exported (see #3440); timeout path should call it and drop the session ## Proposal Patch `Request()` timeout path + skip closed sessions in `selectSession()`, with an integration-style test that blocks the provider longer than the client timeout and asserts the session is removed from the pool. -- 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]
