[jira] [Commented] (OAK-2418) int overflow with orderby causing huge slowdown

["Thomas Mueller (JIRA)" <ji...@apache.org>]

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

Thomas Mueller commented on OAK-2418:
-------------------------------------

Great analysis! The patch locks good to me. 

I will also add a test case.

There is also a possible long overflow in FilterIterators.newCombinedFilter, if limit or offset is are to Long.MAX_VALUE. I will try to fix that as well (or open a new bug).

> 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
>            Assignee: Thomas Mueller
>            Priority: Critical
>             Fix For: 1.2, 1.0.10, 1.1.6
>
>         Attachments: oak-2418.patch
>
>
> 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)