[
https://issues.apache.org/jira/browse/OAK-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493724#comment-14493724
]
Thomas Mueller commented on OAK-2752:
-------------------------------------
I think the patch needs work.
The code in this class looks a bit weird to me, at least it's incorrectly /
poorly documented, as the javadoc says: "Each table entry is either null (when
there are no matching identifiers) or a list of weak references to the matching
identifiers.". Well, a table entry is not a list, it's a reference. So that's
wrong. "Actually, this is a array. It's not a hash map, to conserve memory
(maps need much more memory)." I guess it's actually because of speed, not
memory, because the array is only half full where a hash map is usually 3/4
full. I also wonder why it's an ArrayList and not simply an array. And why it's
using linear probing (and why this is not documented).
The current code seems to assume the is a "null" entry in the list, and this
seems to be enforced in refresh(). But it is not documented. And probably not
correct in some edge cases, this is why it hangs in your case. But the patch
does not fix that, which might be a problem.
> 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.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)
