Nick Shanin created SOLR-18613:
----------------------------------
Summary: Consistently enforce LBSolrClient request attempt limits
Key: SOLR-18613
URL: https://issues.apache.org/jira/browse/SOLR-18613
Project: Solr
Issue Type: Bug
Reporter: Nick Shanin
Following the dev-list discussion "Limiting LBSolrClient retries (inside
CloudSolrClient & HttpShardHandler)" started by Chris Hostetter on October 26,
this issue tracks the first implementation slice: consistent enforcement of the
existing LB request attempt limit.
The standalone {{LBSolrClient.request(..., numServersToTry)}} path can spend
its configured allowance on live endpoints and then continue dispatching
through zombie fallback. A positive limit with an empty live-endpoint snapshot
can also reach server selection with an empty array. When the limit exceeds the
live snapshot, failed live endpoints can be selected repeatedly. In the
asynchronous endpoint-list path, attempt-limit exhaustion can be hidden behind
the preceding transport failure.
h3. Intended behavior
* Count each LB dispatch, including the initial attempt, against one allowance
for that request execution.
* Include both live-endpoint attempts and zombie fallback. Skipping a
known-dead endpoint without dispatching does not consume an attempt.
* Avoid revisiting an exhausted live-endpoint snapshot merely because the
configured limit is larger.
* Preserve an identifiable exhaustion exception with the actual attempt count,
configured maximum, and last failure.
* Keep synchronous and asynchronous behavior consistent, with independent
counters when requests are reused or executed concurrently.
* Preserve unconfigured behavior, deadline handling, cancellation, and
existing restrictions on retrying updates and administrative requests.
The bound covers LB delegate dispatches. HTTP-client-internal retries and
background health checks are outside this count.
h3. Scope
This issue covers {{LBSolrClient}}, {{LBAsyncSolrClient}}, and focused
regression tests. CloudSolrClient defaults and per-request controls, accounting
across stale-state retries, and server/per-shard controls are proposed
follow-up slices. This first slice does not establish a total-node ceiling for
an entire distributed query or make exhaustion terminal across all outer retry
layers.
h3. Implementation and verification
A candidate implementation is on [the fork
branch|https://github.com/nick-boss-tech/solr/tree/solr-lb-attempt-limits-pr1-submit],
currently at {{c2d2c6259462a7e848008b065d65df69a1b82ebb}}. No upstream PR is
open.
Linux verification at {{28dbd2edfce1520c354dbc71b555db4ced3fbebe}} reported 47
tests passing with zero failures, errors, or skips, clean tidy, and a passing
{{check -x test}} in a full clone. Four regression methods failed for the
expected behavioral reasons on the original production code with only an inert
exception-type declaration added so the tests could compile. The other new
assertions remain compatibility coverage.
The published candidate has the same complete Git tree as that tested revision,
but a different commit ID after the formatting and Javadoc repairs were
replayed. Verification at the exact published commit remains pending.
Related issues: SOLR-11107 concerns the threshold for classifying a server as a
zombie; SOLR-18341 concerns request retry eligibility; SOLR-18402 concerns
retry/failure classification. Those changes are outside this issue.
AI-assisted text and implementation; human review pending.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
