lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernhard Frauendienst (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-2855) Large number of range facets causes server to lock up
Date Sun, 20 Nov 2011 12:37:52 GMT


Bernhard Frauendienst commented on SOLR-2855:

I'm afraid I have to agree with you :)

The only reason I filed a bug for this is the huge pain this issue has caused us. It was very
hard to pin down, and it took us ages until we could reproduce it in a testing environment.
It didn't throw any errors, there was _nothing_ in the logs (since the query never completed,
and in the rare cases it did, by that time all queries had insanely high QTimes). The only
thing we saw was the servers locking up.

The problem with start+gap+end is, that they are "easy" to get wrong, compared to, let's say,
I guess the latter is a more common use case anyway, and would save some calculation that
can go haywire on overflows. Using static or stored numbers is always less error prone than
calculated ones.

wrt timeAllowed: Ah, yes, I should have known that one :)

> Large number of range facets causes server to lock up
> -----------------------------------------------------
>                 Key: SOLR-2855
>                 URL:
>             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&}})
> 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:!default.jspa
For more information on JIRA, see:


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

View raw message