[
https://issues.apache.org/jira/browse/HBASE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602019#action_12602019
]
Ning Li commented on HBASE-663:
-------------------------------
The fix is that in HRegion's internalFlushcache():
Change
this.updatesLock.writeLock().lock();
try {
for (HStore s: stores.values()) {
s.snapshot();
}
} finally {
this.updatesLock.writeLock().unlock();
}
long sequenceId = log.startCacheFlush();
To
this.updatesLock.writeLock().lock();
try {
for (HStore s: stores.values()) {
s.snapshot();
}
long sequenceId = log.startCacheFlush();
} finally {
this.updatesLock.writeLock().unlock();
}
> Incorrect sequence number for cache flush
> -----------------------------------------
>
> Key: HBASE-663
> URL: https://issues.apache.org/jira/browse/HBASE-663
> Project: Hadoop HBase
> Issue Type: Bug
> Components: regionserver
> Reporter: Ning Li
> Priority: Minor
>
> An HRegion asks each HStore to flush its cache with a sequence number X. The
> assumption is that all the updates before X will be flushed. So during the
> startup reconstruction, the updates before X are skipped.
> The use of updatesLock should guarantee that all the updates before X will be
> flushed when HStore flushes with X - snapshots are taken after the write lock
> on updatesLock is acquired, while all the updates are written to the log and
> to the cache with the read lock on updatesLock is acquired. However, because
> the sequence number X is obtained without the write lock on updatesLock, some
> updates with sequence number <= X may not have been written to the cache
> which will be flushed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
