[
https://issues.apache.org/jira/browse/OAK-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14626286#comment-14626286
]
Thomas Mueller commented on OAK-3055:
-------------------------------------
One problem is that the segment cache is not "accessed" (as usual for a cache)
when the segment is used, so that it's hard to say which segment should be
evicted. One solution would be to "access" for every 1024th call on average,
for example using a pseudo-random number generator. The regular
java.util.Random would be quite slow for that, instead the following
low-quality random number generator could be used. I measured it's 16 times
faster than java.util.Random:
{noformat}
public class FastRandom {
private int x;
public FastRandom(int seed) {
x = (short) seed;
}
public FastRandom() {
this((int) System.currentTimeMillis());
}
public int nextInt() {
return x = 0xc3e157c1 - Integer.rotateLeft(x, 19);
}
}
{noformat}
> Improve segment cache in SegmentTracker
> ---------------------------------------
>
> Key: OAK-3055
> URL: https://issues.apache.org/jira/browse/OAK-3055
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Labels: resilience, scalability
> Fix For: 1.3.5
>
> Attachments: OAK-3055.patch
>
>
> The hand crafted segment cache in {{SegmentTracker}} is prone to lock
> contentions in concurrent access scenarios. As {{SegmentNodeStore#merge}}
> might also end up acquiring this lock while holding the commit semaphore the
> situation can easily lead to many threads being blocked on the commit
> semaphore. The {{SegmentTracker}} cache doesn't differentiate between read
> and write access, which means that reader threads can block writer threads.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
