[
https://issues.apache.org/jira/browse/HBASE-15716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358632#comment-15358632
]
Hiroshi Ikeda commented on HBASE-15716:
---------------------------------------
Sorry, I found that getSmallestReadPoint() may go backward when getEntry() is
going to adding a new tail node with an already obsolete read point. In order
to keep the consistency between the methods I should have left the decision of
returning the current mvcc read point into the internal queue. Now I'm thinking:
{code}
long getSmallestReadPoint() {
Node head = headRef.get();
while (true) {
long refs = head.references;
if (refs > 0) {
return head.readPoint;
}
Node next = head.next;
if (next == null) {
assert refs == 0;
long mvccReadPoint = getMvccReadPoint();
if (head.readPoint < mvccReadPoint) {
next = new Node(mvccReadPoint, 0);
if (! head.setNextIfAbsent(next)) {
// The following node is asynchronously set.
next = head.next;
}
} else {
return head.readPoint;
}
}
assert next != null;
if (refs < 0 || head.compareAndSetReferences(0, -1)) {
if (headRef.compareAndSet(head, next)) {
head = next;
} else {
head = headRef.get();
}
} // Otherwise head.references is asynchronously changed from 0; Check
again.
}
}
{code}
Or any better idea? Sorry for bothering you.
> HRegion#RegionScannerImpl scannerReadPoints synchronization constrains random
> read
> ----------------------------------------------------------------------------------
>
> Key: HBASE-15716
> URL: https://issues.apache.org/jira/browse/HBASE-15716
> Project: HBase
> Issue Type: Bug
> Components: Performance
> Reporter: stack
> Assignee: stack
> Attachments:
> 15716.implementation.using.ScannerReadPoints.branch-1.patch,
> 15716.prune.synchronizations.patch, 15716.prune.synchronizations.v3.patch,
> 15716.prune.synchronizations.v4.patch, 15716.prune.synchronizations.v4.patch,
> 15716.wip.more_to_be_done.patch, HBASE-15716.branch-1.001.patch,
> HBASE-15716.branch-1.002.patch, HBASE-15716.branch-1.003.patch,
> HBASE-15716.branch-1.004.patch, HBASE-15716.branch-1.005.patch,
> ScannerReadPoints.java, Screen Shot 2016-04-26 at 2.05.45 PM.png, Screen Shot
> 2016-04-26 at 2.06.14 PM.png, Screen Shot 2016-04-26 at 2.07.06 PM.png,
> Screen Shot 2016-04-26 at 2.25.26 PM.png, Screen Shot 2016-04-26 at 6.02.29
> PM.png, Screen Shot 2016-04-27 at 9.49.35 AM.png, Screen Shot 2016-06-30 at
> 9.52.52 PM.png, Screen Shot 2016-06-30 at 9.54.08 PM.png,
> TestScannerReadPoints.java, before_after.png,
> current-branch-1.vs.NoSynchronization.vs.Patch.png, hits.png,
> remove.locks.patch, remove_cslm.patch
>
>
> Here is a [~lhofhansl] special.
> When we construct the region scanner, we get our read point and then store it
> with the scanner instance in a Region scoped CSLM. This is done under a
> synchronize on the CSLM.
> This synchronize on a region-scoped Map creating region scanners is the
> outstanding point of lock contention according to flight recorder (My work
> load is workload c, random reads).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
