serhiy-bzhezytskyy opened a new pull request, #4643: URL: https://github.com/apache/solr/pull/4643
While looking into the graceful-shutdown test failures (SOLR-17764), I noticed `CloudSolrClient.wasCommError()` only classifies `SocketException` and `UnknownHostException` as communication errors worth retrying. A connection dropped mid-request surfaces as a `java.nio.channels.ClosedChannelException` (for example an HTTP/2 GOAWAY when a node shuts down). That was not treated as a comm error, so the request was not retried even though `maxRetries` allowed it — the logs show `commError=false` and no retry. This is the kind of "connection error should be retried" case a couple of committers pointed at on SOLR-17764. Fix: treat `ClosedChannelException` as a communication error, alongside the existing two, so the request is retried on another node when one is available. Added a unit test for the classification. Scope / honesty: this does **not** by itself fix the graceful-shutdown failures in SOLR-17764. - The underlying failure is a Jetty HTTP/2 client bug (jetty#15368) that discards an already-sent response on connection close. I confirmed it still reproduces on Jetty 12.1.11 (bumped + relocked + ran the failing seed 10x), so a version bump does not help. - And for the single-node case in `TestGracefulJettyShutdown`, retry cannot help because there is no other node to route to. So this is a standalone retry-robustness improvement that is correct on its own merits, not a fix for the graceful-shutdown issue. Details and experiments posted on SOLR-17764. -- 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]
