[
https://issues.apache.org/jira/browse/OAK-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371130#comment-14371130
]
Michael Dürig commented on OAK-2654:
------------------------------------
Makes sense I think. Taking this further, is it even necessary to call refresh
on every {{null}} reference? So instead of the boolean {{shouldRefresh}} why
not a counter keeping track of the number of {{null}} references and only
refresh once a certain threshold is reached? With a threshold of {{1}} the
behaviour would be the same as in the patch.
> SegmentIdTable too eager to refresh
> -----------------------------------
>
> Key: OAK-2654
> URL: https://issues.apache.org/jira/browse/OAK-2654
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
> Fix For: 1.1.8, 1.2
>
> Attachments: OAK-2654.patch
>
>
> Calling SegmentIdTable#getSegmentId might trigger a reference table refresh
> if a certain condition is met, I think that this condition is too eager to
> trigger the refresh and in high write scenarios, this results in large pauses
> as the method is synchronized.
> The current condition resembles a cache miss (_index != first_) which means
> that when looking up a segment id by the _lsb_ it might happen that it either
> - is not there, so it needs to be added (no refresh on this branch)
> - or there is an overlap on lsb values (actually on the value returned by
> _getIndex(lsb)_), in which case a refresh will be triggered.
> In high write scenarios the refresh case happens a lot more frequently so a
> refresh is triggered, even if it might not be needed. a refresh makes sense
> when there are null references and it might make sense for them to be
> collected otherwise we're just creating clones of the same map over and over
> again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
