[
https://issues.apache.org/jira/browse/SOLR-15429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350688#comment-17350688
]
Chris M. Hostetter commented on SOLR-15429:
-------------------------------------------
FWIW: I encountered this first hand doing some testing of the main branch using
configs+queries found "in the wild" (from an ecommerce company running solr 8.x
in production) that had a combination of:
* edismax
* sentence length query
* large number of qf fields
* large number of pf fields
* query time synonym expansions
...these queries weren't particularly "slow" or "dangerous" (as compared to the
original "safety net" {{maxBooleanClauses}} has historically provided to
protect against queries that rewrite exponentially and fill up heaps) but they
did wind up pushing (just) over the default 1024 clause limit once the entire
nested query structure was factored in.
----
I don't know that we can/should change the "default" solr.xml setting for this
value – mainly because there is no "one to one" mapping that will neccessarily
make sense in all cases – but at a minimum this change in behavior should be
noted in the "Major Changes" / "Upgrading" section(s) of the ref-guide.
> Solr implications of LUCENE-8811 changes to how (solr.xml's)
> maxBooleanClauses is now used by IndexSearcher
> -----------------------------------------------------------------------------------------------------------
>
> Key: SOLR-15429
> URL: https://issues.apache.org/jira/browse/SOLR-15429
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
>
> {panel:title=Background Info}
> LUCENE-8811 Modified Lucene 9.x to expanded the usage of
> {{BooleanQuery.maxClauseCount}} (now moved to
> {{IndexSearcher.maxClauseCount}})
> Now, in addition to being a limit on the number of individual clauses that
> can be specified when creating _single_ BooleanQuery (either explicitly or
> during {{Query.rewrite()}}) it is also used by a {{QueryVisitor}} (after
> {{Query.rewrite()}} to enforce a limit on the total number of clauses in a
> _nested_ query structure.
> In other words, the following psuedo code will work in lucene 8, but fail in
> lucene 9...
> {code:java}
> x = new BooleanQuery()
> y = new BooleanQuery()
> for (int i = 0; i < BooleanQuery.maxClauseCount - 1; i++) {
> x.addClause(new TermQuery("fx:" + i))
> y.addClause(new TermQuery("fy:" + i))
> }
> BooleanQuery wrapper = new BooleanQuery(x, y)
> searcher.search(wrapper)
> {code}
> {panel}
> {panel:title=(Current) Impacts on Solr users}
> The solr.xml {{maxBooleanClauses}} setting is what currently controls how
> this value is configured. If unset, it defaults to the lucene default
> (unchanged in 9.x) of 1024 – but the solr.xml files shipped with all versions
> of Solr since 8.1 have specified a value of
> {{"\${solr.max.booleanClauses:1024}"}} (see SOLR-13336)
> The direct impacts of LUCENE-8811 on Solr users (as of the current
> solr.git/main branch) is that queries which worked fine in 8.x may start
> throwing {{TooManyClauses()}} exceptions in 9.x, even with existing (built by
> 8.x) indexes, depending on how complex and deeply nested the query structures
> are.
> {panel}
> This jira is being created as a focal point for assess/discussion what
> changes we want to make to Solr code and/or documentation regarding
> {{maxBooleanClauses}} in Solr 9.0.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
