[
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
