[
https://issues.apache.org/jira/browse/SOLR-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055882#comment-16055882
]
Erick Erickson commented on SOLR-4586:
--------------------------------------
[~janhoy]
"last core wins" is my shorthand for the fact that this is static in Lucene. So
when a core loads and it encounters a <maxBooleanClauses> entry it sets this
static.
So let's say core1 has a value of 64 and core2 has a value of 100,000.
If core2 loads last both core1 and core2 have a limit of 100,000.
If core1 loads last both core1 and core2 have a limit of 64.
And since you can load cores in parallel it's not even determinate which one
will always load last.
This is especially problematic in SolrCloud when you have heterogeneous
collections sharing JVMs and users are left wondering why they got this
exception after bumping the limit up. Not to mention adding a replica to some
core someplace may suddenly cause the replicas on that JVM to fail. Imagine my
limit is 100,000 for collection1 and all the replicas on a particular JVM are
from collection1. Now I create a new collection with a different config set.
BOOM.
> Eliminate the maxBooleanClauses limit
> -------------------------------------
>
> Key: SOLR-4586
> URL: https://issues.apache.org/jira/browse/SOLR-4586
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 4.2
> Environment: 4.3-SNAPSHOT 1456767M - ncindex - 2013-03-15 13:11:50
> Reporter: Shawn Heisey
> Fix For: master (7.0)
>
> Attachments: SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch,
> SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch,
> SOLR-4586_verify_maxClauses.patch
>
>
> In the #solr IRC channel, I mentioned the maxBooleanClauses limitation to
> someone asking a question about queries. Mark Miller told me that
> maxBooleanClauses no longer applies, that the limitation was removed from
> Lucene sometime in the 3.x series. The config still shows up in the example
> even in the just-released 4.2.
> Checking through the source code, I found that the config option is parsed
> and the value stored in objects, but does not actually seem to be used by
> anything. I removed every trace of it that I could find, and all tests still
> pass.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
