Himanshu Vashishtha created HBASE-10577:
-------------------------------------------
Summary: Remove unnecessary looping in FSHLog
Key: HBASE-10577
URL: https://issues.apache.org/jira/browse/HBASE-10577
Project: HBase
Issue Type: Bug
Components: wal
Affects Versions: 0.99.0
Reporter: Himanshu Vashishtha
In the new disruptor based FSHLog, the Syncer threads are handed a batch of
SyncFuture objects from the RingBufferHandler. The Syncer then invokes a sync
call on the current writer instance.
This handing of batch is done in serially in RingBufferHandler, that is, every
syncer receives a non overlapping batch of SyncFutures. Once synced, Syncer
thread updates highestSyncedSequence.
In the run method of Syncer, we have:
{code}
long currentHighestSyncedSequence = highestSyncedSequence.get();
if (currentSequence < currentHighestSyncedSequence) {
syncCount += releaseSyncFuture(takeSyncFuture,
currentHighestSyncedSequence, null);
// Done with the 'take'. Go around again and do a new 'take'.
continue;
}
{code}
I find this logic of polling the BlockingQueue again in this condition
un-necessary. When the currentHighestSyncedSequence is already greater than
currentSequence, then doesn't it mean some other Syncer has already synced
SyncFuture of these ops ? And, we should just go ahead and release all the
SyncFutures for this batch to unblock the handlers. That would avoid polling
the Blockingqueue for all SyncFuture objects in this case.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
