[
https://issues.apache.org/jira/browse/SOLR-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13228990#comment-13228990
]
Bill Bell commented on SOLR-3085:
---------------------------------
We also found another loophole. If we send [* TO *] to edismax we also can
bring down the server.
Some chars are not being escaped before being sent to SOLR. Eg I can send
queries like this to SOLR by searching on ([* TO *] OR [* TO *] OR [* TO *]) in
the search box - it took 72 seconds to return:
webapp=/solr path=/select
params={d=160.9344&start=0&q=([*+TO+*]+OR+[*+TO+*]+OR+[*+TO+*])&pt=40.7146,-74.0071&qt=providersearchdist&wt=json&qq=city_state_lower:"new+york,+ny"&rows=20}
hits=276442 status=0 QTime=72458
> Fix the dismax/edismax stopwords mm issue
> -----------------------------------------
>
> Key: SOLR-3085
> URL: https://issues.apache.org/jira/browse/SOLR-3085
> Project: Solr
> Issue Type: Bug
> Components: search
> Reporter: Jan Høydahl
> Labels: MinimumShouldMatch, dismax, stopwords
> Fix For: 3.6, 4.0
>
>
> As discussed here http://search-lucene.com/m/Wr7iz1a95jx and here
> http://search-lucene.com/m/Yne042qEyCq1 and here
> http://search-lucene.com/m/RfAp82nSsla DisMax has an issue with stopwords if
> not all fields used in QF have exactly same stopword lists.
> Typical solution is to not use stopwords or harmonize stopword lists across
> all fields in your QF, or relax the MM to a lower percentag. Sometimes these
> are not acceptable workarounds, and we should find a better solution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
