Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
Some Solr operations, while useful in many circumstances, are so expensive or dangerous in others that we warn users against using them in the ref-guide. Unfortunately though not everyone reads the full ref-guide, so some users still stumble into these pitfalls unawares. We should, if possible, give users a slightly more forcible nudge away from these operations at runtime.
One model for how to do this already exists in Solr's maxBooleanClauses "soft-limit" setting. (Bugs with maxBooleanClauses have caused confusion historically, but the core approach is sound.) Dangerous operations are gated by a user-configurable "soft" limit that is "on" by default. Users may hit this at runtime and notice the error, forcing a discussion about whether the functionality is needed and whether the "safety" tradeoff is acceptable. Following this discussion users are free to loosen or tighten the limit as they see fit.
There are a number of operations, parameters, etc. that might benefit from this treatment, including:
- minimum "prefix length" in a prefix query
- naive "deep-paging"
- maximum fields per core (to guard against dynamic field misconfiguration creating a core with thousands of fields)
- maximum cores per node (maybe?)
- etc.
This JIRA aims to serve as an "umbrella ticket" covering overall progress on these sort of limits. See sub-task tickets for progress on specific limits.
Attachments
1.
|
Maximum-fields-per-core soft limit | Closed | Jason Gerlowski |
|
||||||||
2.
|
Naive-deep-paging soft limit | Open | Unassigned | |||||||||
3.
|
Minimum prefix-length soft limit | Closed | Jason Gerlowski |
|