[
https://issues.apache.org/jira/browse/SOLR-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150209#comment-13150209
]
Hoss Man commented on SOLR-2855:
--------------------------------
bq. Throwing an exception if more ranges than the facet.limit value (or a
similar, new parameter) for this field would be generated might be a good
solution.
There are already params that specify a limit on the number of ranges computed:
they are facet.range.start + facet.range.end + facet.range.gap. If those
values are computed programaticly by a client, adding a new
"facet.range.max.expected.ranges" param wouldn't make this problem go away
since the client could just as easily compute an incorrect value for the new
facet.range.max.expected.ranges param as well.
If you'd like to submit a patch to add a new sanity checking param like this
for range faceting you're free to do so -- but personally i don't see a lot of
value. the general problem description is "Client code sent request that asked
solr to do more work then client really wanted" and a single example of that is
range faceting -- other examples would be really big values for the rows or
facet.limit or timeAllowed params, or using "fl=*" on an index with thousands
of stored fields ... at a certain point we have to just assume the client app
really does want what it asked for
FWIW...
bq. b) the query isn't aborted by overstepping the timeAllowed value
As documented, timeAllowed is only applied to the *search* for queries matching
the document, not total request processing (ie: it doesn't affect request
parsing, query parsing, faceting, highlighting, response writing, etc...)
https://wiki.apache.org/solr/CommonQueryParameters#timeAllowed
> Large number of range facets causes server to lock up
> -----------------------------------------------------
>
> Key: SOLR-2855
> URL: https://issues.apache.org/jira/browse/SOLR-2855
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
> Affects Versions: 3.4
> Reporter: Bernhard Frauendienst
> Labels: facet, range
>
> (NOTE: I'm aware that this is not exactly a BUG in the sense that something
> is not working correctly, but it is still something that might be considered
> to be changed.)
> A bug in our code triggered an integer overflow which caused very large range
> facets to be requested on a TrieIntField
> (e.g.
> {{facet.range.start=*-2147483648*&facet.range.end=1000&facet.range.gap=1}})
> This caused the Solr server to allocate huge amounts of memory so that it
> soon had filled up the whole 18 GB the JVM had available, and the Garbage
> Collector wasn't able to free it (fast enough?) and was thus taking up nearly
> all of the CPU, which finally led to a complete Denial of Service.
> While the cause for this behavior obviously lies within the buggy code, it
> might still be desirable for Solr not to lock up for "wrong" parameters but
> throw an error instead.
> Throwing an exception if more ranges than the {{facet.limit}} value (or a
> similar, new parameter) for this field would be generated might be a good
> 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]
