[
https://issues.apache.org/jira/browse/HBASE-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017997#comment-14017997
]
stack commented on HBASE-10577:
-------------------------------
Closing as 'wont fix'.
I think we need what we have here because SyncRunners run for the life of the
RS with batches being added to the SyncRunner queue continuously by the Writer
thread; i.e. we are not taking a batch, running, then taking a new batch.
We are being careful we don't go beyond the currently highest sync'd sequence
id. While someone else may have let go of all our handlers after pushing the
highest sequence id beyond our current sync future, there is nothing preventing
the Writer thread adding a new batch of Sync Futures concurrently.
Please reopen if I am not understanding correctly. 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.2#6252)
