Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 3 Nov 2011 12:09:32 +0000 (UTC)
From: "Bernhard Frauendienst (Commented) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <886091340.55278.1320322172724.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2059017092.18633.1319644292541.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-2855) Large number of range facets causes
 server to lock up
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143059#comment-13143059 ] 

Bernhard Frauendienst commented on SOLR-2855:
---------------------------------------------

I would like to add that
a) the server doesn't run out of memory (in the sense of OOM), but allocates so many objects in such a short time (several Gigabytes per second in our setup) that the GC doesn't catch up and take up all CPU time
b) the query isn't aborted by overstepping the timeAllowed value
                
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org