lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Bell (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3085) Fix the dismax/edismax stopwords mm issue
Date Wed, 14 Mar 2012 05:37:44 GMT


Bill Bell commented on SOLR-3085:

We also found another loophole. If we send [* TO *] to edismax we also can bring down the

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:
>             Project: Solr
>          Issue Type: Bug
>          Components: search
>            Reporter: Jan H√łydahl
>              Labels: MinimumShouldMatch, dismax, stopwords
>             Fix For: 3.6, 4.0
> As discussed here and here
and here 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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message