janhoy commented on code in PR #2069: URL: https://github.com/apache/solr/pull/2069#discussion_r1391100250
########## solr/solr-ref-guide/modules/deployment-guide/pages/circuit-breakers.adoc: ########## @@ -32,8 +32,25 @@ Setting the `shards.tolerant=true` parameter on requests can help with graceful circuit breaker thresholds are reached on some nodes. See the <<shards.tolerant Parameter>> for details. == Circuit Breaker Configurations -All circuit breaker configurations are listed as independent `<circuitBreaker>` entries in `solrconfig.xml` as shown below. -A circuit breaker can register itself to trip for query requests and/or update requests. By default only search requests are affected. A user may register multiple circuit breakers of the same type with different thresholds for each request type. +Circuit breakers can be configured globally for the entire node, or for each collection individually, or a combination. Per-collection circit breakers take precedence over global circuit breakers. Review Comment: > Or put another way, it's always the lowest threshold that takes precedence? I think most users will choose either configuring globally or per core. I really only see utility (from a protect server from over-heating perspective) in the global config. But if a user chooses to do both, my thinking was that they should be allowed to do it in any fashion they like, which includes shooting themselves in the foot by allowing higher or lower values for a particular collection than the global. There may be reasons for both, and I don't think we should dictate what they can do. The only environment where I can see it would be beneficial to prevent collections from overriding would be in multi tenant environments where you as cluster owner want to maintain full control. But IMO such requirements should come from those kind of users and it can be provided as a future config option to either disable collection-level CB entirely or fine grained precedence rules of some kind. I feel it is premature to guess those needs in this first feature introduction, so keeping it simple. -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
