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)