You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Himanshu Vashishtha (JIRA)" <ji...@apache.org> on 2014/02/20 18:32:19 UTC

[jira] [Created] (HBASE-10577) Remove unnecessary looping in FSHLog

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)