[
https://issues.apache.org/jira/browse/SOLR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3652:
---------------------------
Summary: Range Faceting will infinite loop if gap is too small relative to
lower bounds of range (underflow occurs on add) (was: Range Faceting can't
handle large bounds in some situations )
bq. Looking at the patch, this seems to just raise an exception with large
numbers, not actually support them.
There isn't actually a problem with "large" numbers -- the real problem is
actually with "small" numbers -- specifically the root cause of the infinite
looping was when the "gap" was too small, _relative to the the start/end_, for
the field type in use (float), and became effectively the same as "zero".
That's what this patch fixes. If adding the gap to the lower bound of a range
produces a value that is still equal to the lower bound, it fails rather the
going into an infinite loop.
bq. Would it be possible to support large ranges?
large ranges can work fine -- use a "big" gap and you will never see this
problem. what doesn't work is having a range so small that for the field type
being used, the lower and upper bounds are equivalent for some values.
bq. ...could that tie me over until the behaviour is actually fixed? Or is it
a limitation with sig figs, and not the absolute value?
This is really a fundamental limitation based on the underlying data types
being used. If you use a "float" field type in Solr, the underlying
representation is constrained by the valid values that can be represented by a
java Float. likewise for "double" ...
http://docs.oracle.com/javase/6/docs/api/java/lang/Float.html
http://docs.oracle.com/javase/6/docs/api/java/lang/Double.html
...if your field type is "float" and you ask for something like
{{facet.range.start=100000000000&facet.range.end=100000086200&facet.range.gap=2160}}}
then eventually, as FacetComponent computes the individual ranges, it's going
to try and compute a range where the lower bound is "9.9999998E10" -- but for
float values, "9.9999998E10 + 2160 = 9.9999998E10" and that's where the
infinite loop underflow error check will abort the request. There's really
nothing else it can do.
If you try the same request with a "double" field or a "long" field and
everything will work fine for this particular example, but a java "float" can't
express a difference between "9.9999998E10" and "9.9999998E10 + 2160"
> Range Faceting will infinite loop if gap is too small relative to lower
> bounds of range (underflow occurs on add)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-3652
> URL: https://issues.apache.org/jira/browse/SOLR-3652
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.0-ALPHA, 3.6.1
> Environment: OSX Lion, Macbook Pro, 8GB Ram
> Reporter: Nicholas Jakobsen
> Assignee: Hoss Man
> Labels: facet, range
> Fix For: 4.0
>
> Attachments: SOLR-3652.patch
>
>
> Executing the following query will lock up the java process running solr.
> facet=true&facet.range=item_search__creation_event_facet_range_ftm&f.item_search__creation_event_facet_range_ftm.facet.range.start=100000000000.0&f.item_search__creation_event_facet_range_ftm.facet.range.end=100000086200.0&f.item_search__creation_event_facet_range_ftm.facet.range.gap=2160.0&q=%2A%3A%2A
> But decreasing the size of the min and max works fine
> facet=true&facet.range=item_search__creation_event_facet_range_ftm&f.item_search__creation_event_facet_range_ftm.facet.range.start=10000000000.0&f.item_search__creation_event_facet_range_ftm.facet.range.end=10000086200.0&f.item_search__creation_event_facet_range_ftm.facet.range.gap=2160.0&q=%2A%3A%2A
> And so does increasing the range gap
> facet=true&facet.range=item_search__creation_event_facet_range_ftm&f.item_search__creation_event_facet_range_ftm.facet.range.start=100000000000.0&f.item_search__creation_event_facet_range_ftm.facet.range.end=100000086200.0&f.item_search__creation_event_facet_range_ftm.facet.range.gap=21600.0&q=%2A%3A%2A
--
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]
