[
https://issues.apache.org/jira/browse/OAK-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493803#comment-14493803
]
Thomas Mueller commented on OAK-2752:
-------------------------------------
> OAK-2654
I see the problem now, yes that makes sense. I guess the bug was introduced in
OAK-2654 because the class is poorly documented and tested, so that should be
fixed.
A problem of OAK-2654 is that it slows down read access, if the table is almost
full. Basically you end up with a hash table that has an access cost of O(n)
instead of the O(1). Sure, you avoid frequent resizes on put, so in many cases
put is no longer O(n) but O(1). But at the cost of potentially very high cost
on get.
> SegmentIdTable can sometimes hang when calling getSegmentId(msb, lsb)
> ---------------------------------------------------------------------
>
> Key: OAK-2752
> URL: https://issues.apache.org/jira/browse/OAK-2752
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-core
> Affects Versions: 1.2
> Reporter: Will McGauley
> Assignee: Alex Parvulescu
> Priority: Critical
> Fix For: 1.0.13, 1.2.1
>
> Attachments: OAK-2752-v2.patch, OAK-2752.patch
>
>
> The while loop getSegmentId(msb, lsb) loops forever in the situation where
> the segment id is not found.
> Looping occurs from 'first' and loops to the end of the SegmentId references,
> and then loops back to first. If the segmentid is not found in any of the
> referenced items then looping continues past 'first' again and loops for
> eternity through all the references.
> See attached patch for possible fix to break out of the loop after getting
> back to 'first' again.
> note: I have tested this patch on my system and it seems to work, but I do
> not know if the patch provides the best fix, I am a bit new to this code.
> The most important part of the patch would be the break condition from the
> loop so the loop does not continue after testing each reference
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
