You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2011/09/23 16:44:26 UTC

[jira] [Updated] (JCR-2734) Inconsistencies in BitSetKey comparison

     [ https://issues.apache.org/jira/browse/JCR-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated JCR-2734:
-------------------------------

    Fix Version/s: 2.2.0
                   2.1.6
                   2.0.4

Merged to the 2.1 branch in revision 1174814 and to the 2.0 branch in revision 1174815.

> Inconsistencies in BitSetKey comparison
> ---------------------------------------
>
>                 Key: JCR-2734
>                 URL: https://issues.apache.org/jira/browse/JCR-2734
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, nodetype
>    Affects Versions: 2.1.1
>            Reporter: Thomas Draier
>            Assignee: Stefan Guggisberg
>             Fix For: 2.0.4, 2.1.6, 2.2.0
>
>         Attachments: JCR-2734.patch
>
>
> Hi,
> I encountered a problem with the BitsetENTCacheImpl and the BitsetKey comparisons. I have 3 bitsets A, B and C , defined as :
> A : bits 0,4,17,38,60,63 
> B : bits 4,17,38,52,59,60
> C : bits 0,17,38,60,61,63
> If call BitsetKey.compareTo  method on each pair , i get : 
> A < B
> B < C
> C < A
> which is not correct and leads to inconsistencies in the TreeSet.
> All 2 bitsets are contained in one single word (max bit is 63). So, the method is comparing first the 32 MSB - which are enough in that case to compare the bits. But the problem is, that the difference between the 32 MSB of B and C is too big to fit in an integer : for B, we have 403701824 - for C , 2952790080 . The difference between both is 2549088256 (positive) , which is bigger than Integer.MAX_VALUE , and makes a  -1745879040 (negative) after casting to an int .
> In order to fix that, the shift should either be bigger in order to fit a signed integer ( 33 instead of 32 ), or a simple -1 / 0 / +1 could be returned

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira