You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2015/01/19 14:55:34 UTC
[jira] [Updated] (OAK-2418) int overflow with orderby causing huge
slowdown
[ https://issues.apache.org/jira/browse/OAK-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Egli updated OAK-2418:
-----------------------------
Description:
Consider the following query:
{code}
//element(*,slingevent:Job) order by @slingevent:created ascending
{code}
this query - when running with a large number of slingevent:Job around - will take a very long time due to the fact, that FilterIterators.SortIterator.init() in the following loop:
{code}
if (list.size() > max * 2) {
// remove tail entries right now, to save memory
Collections.sort(list, orderBy);
keepFirst(list, max);
}
{code}
does a multiplication with 'max', which is by default set to Integer.MAX_VALUE (see FilterIterators.newCombinedFilter). This results in max *2 to overflow (result is -2) - thus that init-loop will sort the list for every additional entry. Which is definitely not the intention.
was:
Consider the following query:
{code}
//element(*,slingevent:Job) order by @slingevent:created ascending
{code}
this query - when running with a large number of slingevent:Job around - will take a very long time due to the fact, that FilterIterators.SortIterator.init() in the following loop:
{code}
if (list.size() > max * 2) {
// remove tail entries right now, to save memory
Collections.sort(list, orderBy);
keepFirst(list, max);
}
{code}
does a multiplication with 'max', which is by default set to Integer.MAX_VALUE (see FilterIterators.newCombinedFilter). This results in max *2 to overflow (result is -2) - thus that init-loop to sort the list for every additional entry. Which is definitely not the intention.
> int overflow with orderby causing huge slowdown
> -----------------------------------------------
>
> Key: OAK-2418
> URL: https://issues.apache.org/jira/browse/OAK-2418
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0.9
> Reporter: Stefan Egli
> Priority: Critical
>
> Consider the following query:
> {code}
> //element(*,slingevent:Job) order by @slingevent:created ascending
> {code}
> this query - when running with a large number of slingevent:Job around - will take a very long time due to the fact, that FilterIterators.SortIterator.init() in the following loop:
> {code}
> if (list.size() > max * 2) {
> // remove tail entries right now, to save memory
> Collections.sort(list, orderBy);
> keepFirst(list, max);
> }
> {code}
> does a multiplication with 'max', which is by default set to Integer.MAX_VALUE (see FilterIterators.newCombinedFilter). This results in max *2 to overflow (result is -2) - thus that init-loop will sort the list for every additional entry. Which is definitely not the intention.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)