[
https://issues.apache.org/jira/browse/OAK-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628126#comment-14628126
]
Michael Dürig commented on OAK-3055:
------------------------------------
I went with an implementation along the lines of this \[1]. Although in my case
I *do have* concurrent threads accessing the rng, I figured this is not too
problematic as the race in updating {{x}} will only create a slight tilt in the
random numbers, which should not be problematic for the given use case.
An alternative implementation could use {{AtomicInteger.compareAndSet}} for
{{x}}:
{code}
int i = x.get();
int j = 0xc3e157c1 - rotateLeft(i, 19);
while (!x.compareAndSet(i, j)) {
i = x.get();
j = 0xc3e157c1 - rotateLeft(i, 19);
}
{code}
Please go ahead if you think this could be further optimised.
\[1]
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentId.java?r1=1691220&r2=1691219&pathrev=1691220
> 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: doc-impacting, resilience, scalability
> Fix For: 1.3.3
>
> 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)
