[
https://issues.apache.org/jira/browse/HBASE-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13907212#comment-13907212
]
Himanshu Vashishtha commented on HBASE-10577:
---------------------------------------------
What do you think [~stack] ? Thanks.
> 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)
