[jira] [Commented] (HBASE-10577) Remove unnecessary looping in FSHLog
[
https://issues.apache.org/jira/browse/HBASE-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080372#comment-14080372
]
Sean Busbey commented on HBASE-10577:
-
I think this ticket is meant to be closed?
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)
[jira] [Commented] (HBASE-10577) Remove unnecessary looping in FSHLog
[
https://issues.apache.org/jira/browse/HBASE-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (HBASE-10577) Remove unnecessary looping in FSHLog
[
https://issues.apache.org/jira/browse/HBASE-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
