I'm not even sure what this is intended to produce. All documents with terms two or more characters long? What use-case is this intended to solve?
Because unless there's a _really_ good reason to do this, I'd just dis-allow pure-wildcard queries on the app end. This seems like an "XY" question. Perhaps a better thing to investigate is why this kind of query is considered useful and if there's any way to support that use case without trying this awful query :). Best, Erick On Thu, Mar 27, 2014 at 3:18 PM, Michael Ryan <mr...@moreover.com> wrote: > Unfortunately the timeAllowed parameter doesn't apply to the part of the > processing that makes wildcard queries so slow. It only applies to a later > part of the processing when the matching documents are being collected. > There's some discussion in the original ticket that implemented this > (https://issues.apache.org/jira/browse/SOLR-502). I'm not sure if there's a > newer ticket for implementing an end-to-end timeout. > > -Michael > > -----Original Message----- > From: Mario-Leander Reimer [mailto:mario-leander.rei...@qaware.de] > Sent: Thursday, March 27, 2014 12:15 PM > To: solr-user@lucene.apache.org > Subject: timeAllowed query parameter not working? > > Hi Solr users, > > > > currently I have some really long running user entered pure wildcards queries > (like *??) , these are hogging the CPU for several minutes. > > > > So what I tried is setting the "timeAllowed" query parameter via the search > handler in solrconfig.xml. But without any luck, the parameter does not seem > tob e working. Here is my search handler definition: > > > > <requestHandler name="/select" class="solr.SearchHandler" default="true"> > > <lst name="defaults"> > > <int name="rows">10</int> > > <str name="df">TEXT</str> > > <int name="timeAllowed">10000</int> > > </lst> > > </requestHandler> > > > > Thanks for your help! > > Leander
