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=rows10/int
str name=dfTEXT/str
int name=timeAllowed1/int
/lst
/requestHandler
Thanks for your help!
Leander
