serhiy-bzhezytskyy commented on PR #4638: URL: https://github.com/apache/solr/pull/4638#issuecomment-5106959843
Created as SOLR-9355 rather than a new issue — Erick Erickson opened that one in 2016 asking for exactly this retry, and it turned out your note explains why it never fired. PR is #4678. What it came to: `checkRetry` asked the retriability question two different ways depending on which exception was outermost, unwrapping only when it was a `SolrServerException`. Since the async client reports a connection failure as a raw `ExecutionException`, that branch leaf-tested the wrapper and the update wasn't retried. Both node types now scan the cause chain instead; the retriable set and the retry bound are unchanged. One thing I got wrong in my earlier reply here: I said unrolling to the root cause was the better shape. It isn't quite — Jetty's `ClientConnector` wraps an underlying failure in a `SocketException` of its own, so `getRootCause` can walk straight past the frame that matters. Scanning the chain covers both that and the wrapped-from-above case. Your observation also generalised further than the split. Five places in Solr decide retriability with five different sets, and `ConnectException` is the only type all of them agree on — that's on SOLR-9355 as a separate design flag, not something I'm widening anywhere. Nothing needed from you here; #4638 is unchanged. -- 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]
