Skip to content

SOLR-17764: retry CloudSolrClient requests failing with ClosedChannelException#4643

Open
serhiy-bzhezytskyy wants to merge 1 commit into
apache:mainfrom
serhiy-bzhezytskyy:SOLR-17764-retry-closedchannel
Open

SOLR-17764: retry CloudSolrClient requests failing with ClosedChannelException#4643
serhiy-bzhezytskyy wants to merge 1 commit into
apache:mainfrom
serhiy-bzhezytskyy:SOLR-17764-retry-closedchannel

Conversation

@serhiy-bzhezytskyy

Copy link
Copy Markdown
Contributor

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.

…Exception

CloudSolrClient.wasCommError() classified only SocketException and
UnknownHostException as communication errors worth retrying. A connection dropped
mid-request surfaces as a ClosedChannelException (for example an HTTP/2 GOAWAY when
a node shuts down), which was not retried even though maxRetries allowed it.

Treat ClosedChannelException as a communication error so the request is retried on
another node when one is available.

Note: this does not by itself fix the graceful-shutdown failures tracked in
SOLR-17764 (the underlying Jetty HTTP/2 client bug jetty#15368 discards an
already-sent response, and a single-node cluster has no other node to retry on),
but retrying a dropped connection is correct regardless.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant