hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HBASE-10577) Remove unnecessary looping in FSHLog
Date Thu, 31 Jul 2014 06:41:38 GMT

     [ https://issues.apache.org/jira/browse/HBASE-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

stack resolved HBASE-10577.
---------------------------

    Resolution: Won't Fix

(You are right [~busbey])

> 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)

Mime
View raw message