[
https://issues.apache.org/jira/browse/SOLR-18613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-18613:
----------------------------------
Labels: pull-request-available (was: )
> 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
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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]
