[ https://issues.apache.org/jira/browse/JCR-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma updated JCR-3581: --------------------------- Attachment: JCR-3581.patch The JCR-3581.patch was created against current trunk but should be applicable for many previous version branches as well as this code hasn't been changed in a long while. > Incorrect bitwise arithmetic in BitsetENTCacheImpl.BitsetKey.compareTo > implementation - wrong bit mask value used > ------------------------------------------------------------------------------------------------------------------- > > Key: JCR-3581 > URL: https://issues.apache.org/jira/browse/JCR-3581 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core, jackrabbit-jcr2spi > Affects Versions: 2.6, 2.7 > Reporter: Ate Douma > Attachments: JCR-3581.patch > > > The BitsetKey class encodes Names bitwise in one or more long values. > For its Comparable.compareTo implementation, the long value(s) are compared > first by ">>> 32" shifting to compare the higher bits, and if that equals out > by comparing the lower 32 bits. > The bug is in the latter part: instead of masking off the higher 32 bits > using "& 0x0ffffffffL", the current code is masking the higher 48 bits using > "& 0x0ffffL", as shown in snippet below from the current compareTo > implementation: > long w1 = adr<bits.length ? bits[adr] : 0; > long w2 = adr<o.bits.length ? o.bits[adr] : 0; > if (w1 != w2) { > // some signed arithmetic here > long h1 = w1 >>> 32; > long h2 = w2 >>> 32; > if (h1 == h2) { > h1 = w1 & 0x0ffffL; > h2 = w2 & 0x0ffffL; > } > return Long.signum(h2 - h1); > } > As result of this error many possible keys cannot and will not be stored in > the BitsetENTCacheImpl private TreeSet<Key> sortedKeys: only one key for > every key with a value between 0x0ffffL and 0x0ffffffffL (for *each* long > field) will be stored. > Note that such 'duplicate' keys however will be used and stored in the other > BitsetENTCacheImpl private HashMap<Key, EffectiveNodeType> aggregates. > As far as I can tell this doesn't really 'break' the functionality, but can > lead to many redundant and unnecessary (re)creation of keys and entries in > the aggregates map. > The fix of course is easy but I will also provide a patch file with fixes for > the two (largely duplicate?) BitsetENTCacheImpl implementations > (jackrabbit-core and jackrabbit-jcr2spi). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira