[
https://issues.apache.org/jira/browse/HBASE-15716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358316#comment-15358316
]
Hiroshi Ikeda commented on HBASE-15716:
---------------------------------------
I meant, in Listener.doAccept, change
{code}
Reader reader = getReader();
try {
reader.startAdd();
SelectionKey readKey = reader.registerChannel(channel);
// calling channel.register(readSelector, SelectionKey.OP_READ),
// possibly blocked until the reader returns from the
readSelector.select,
// depending on VM implementations
c = getConnection(channel, System.currentTimeMillis());
readKey.attach(c);
...
} finally {
reader.finishAdd();
// The reader will be blocked until calling this.
}
{code}
with
{code}
Reader reader = getReader();
c = getConnection(channel, System.currentTimeMillis());
...
reader.registrationQueue.offer(c);
// The channel is still just-accepted, and the reader thread will register
later.
reader.readSelector.wakeup();
{code}
In Reader.doRunLoop, change
{code}
readSelector.select();
while (adding) {
this.wait(1000);
}
...
{code}
with
{code}
readSelector.select();
Connection c;
while ((c = registrationQueue.poll()) != null) {
// Register anything in the queue.
try {
c.channel.register(readSelector, SelectionKey.OP_READ, c)
} catch (ClosedChannelException e) {
// The channel is already closed somewhere.
// That's legal, and you might want to just log something.
}
}
...
{code}
That is a little part of the logic of the patch I created in HBASE-14479.
Selector is subtle against multi-threads.
> 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, 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, 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)
