[
https://issues.apache.org/jira/browse/SOLR-16974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765030#comment-17765030
]
Jan Høydahl commented on SOLR-16974:
------------------------------------
Could be a solution. Or even simpler, if you have ANY per-core breakers at all,
we do not check the global ones. We might even need a global setting for
whether per-core circuit breakers are allowed in this cluster or not. Imagine a
multi-tenant cluster with 100s or clients. If one client was allowed to disable
breakers and affect all other users it would be bad. If they are disallowed,
the registry would simply reject them with a warn log. Or we could have a
setting where cluster owner can choose three modes:
{{solr.circuitbreakers.per-core-mode= <redefine | disallowe | inherit>}}
> Global Circuit Breakers
> -----------------------
>
> Key: SOLR-16974
> URL: https://issues.apache.org/jira/browse/SOLR-16974
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Circuit Breakers
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently Circuit Breakers are configured per core in solrconfig.xml.
> However, cores/collections do not live in isolation, and it could be that a
> cluster administrator would like to enforce circuit breakers for the entire
> cluster.
> I'm not clear as to whether we need both cluster level and a core level
> pluggability. And would core-level breakers add to any cluster-level ones or
> override them for that core?
> A potential design is to add this as a new plugin in solr.xml, and have them
> added in a new static context of CircuitBreakerRegistry. Then the isTripped
> logic would consult both the per-core list and the static/global list of
> breakers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
