SOLR-17084: Don't return full list of zombie in Exception #2097
Conversation
There was a problem hiding this comment.
If I imagine seeing this error printed somewhere, I'd be confused as to what this number is/means. I might think; is this the number of live Solr Servers? (I would be wrong).
"Maybe print "No live SolrServers/cores available to handle this request. (Tracking 999 not live)"
WDYT?
|
I agree. I changed the PR accordingly. |
|
Cool; can you please add a CHANGES.txt entry to the 9.5 section... I suppose as a Bug but I could also see this as an Improvement or Optimization if you prefer. It's sort of a "scale bug" but one might say there is no such thing; it's an optimization. Shrug. I guess I prefer Optimization but I'll let you pick. Proposed text: "LBSolrClient (used by CloudSolrClient) can potentially return a VERY long error message if it can't route a request when there are many cores tracked as not live AKA zombies. Just return the count of such cores instead of printing them. |
|
update the CHANGES.txt. My PR is against main. I suppose you want to also merge in 9.5 right ? |
|
I looked into the one test failure and I filed an issue to track: https://issues.apache.org/jira/browse/SOLR-17092 |
…s" (#2097) LBSolrClient (used by CloudSolrClient) now returns the count of core tracked as not live AKA zombies instead of the full list of cores. This list is potentially VERY long which was causing high CPU and memory usage.
https://issues.apache.org/jira/browse/SOLR-17084
Description
Exceptions returned by LBSolrClient can become very large. Building and returning them can consume large amount of ressources.
Solution
Exceptions should not contain the full list of zombie replicas but only its count.
Tests
No tests added since the change is really simpl
Checklist
Please review the following and check all that apply:
mainbranch../gradlew check.