Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <26855548.91841283254854436.JavaMail.jira@thor>
Date: Tue, 31 Aug 2010 07:40:54 -0400 (EDT)
From: "Thomas Draier (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (JCR-2734) Inconsistencies in BitSetKey comparison
In-Reply-To: <8421160.91041283250716256.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Thomas Draier updated JCR-2734:
-------------------------------

    Attachment: JCR-2734.patch

> 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
>    Affects Versions: 2.1.1
>            Reporter: Thomas Draier
>         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.
-
You can reply to this email to add a comment to the issue online.