[
https://issues.apache.org/jira/browse/SOLR-16982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012270#comment-18012270
]
Russell Black edited comment on SOLR-16982 at 8/6/25 3:10 AM:
--------------------------------------------------------------
This ticket makes circuit breakers useless for me (and probably others). For a
sharded system, the searches are performed by the internal requests to the
individual shards, which places additional load on them, even if their CPU is
pegged and would otherwise break the circuit. The problem of a circuit-broken
shard in an internal request could be handled by simply recognizing the
returned 429 for what it is, and handling it gracefully (setting response to
partial results).
was (Author: rblack):
This ticket makes circuit breakers useless for me. For a sharded system, the
searches are performed by the internal requests to the individual shards, which
places additional load on them, even if their CPU is pegged and would otherwise
break the circuit. The problem of a circuit-broken shard in an internal
request could be handled by simply recognizing the returned 429 for what it is,
and handling it gracefully (setting response to partial results).
> Trip a Circuit Breaker only for external requests
> -------------------------------------------------
>
> Key: SOLR-16982
> URL: https://issues.apache.org/jira/browse/SOLR-16982
> Project: Solr
> Issue Type: Improvement
> Components: Circuit Breakers
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Major
> Fix For: 9.4
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In a sharded system, Circuit Breakers may now break a shard-request, failing
> the entire query request and in worst-case cause data loss (?) in an update
> request.
> We should see whether we can skip CB checking for the internal requests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
