[
https://issues.apache.org/jira/browse/HBASE-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13397406#comment-13397406
]
Xing Shi commented on HBASE-6195:
---------------------------------
@Ted, I find that if there is no flushcache, there could be three increments in
one millisecond(depends on the machine).
I made all the timestamps (variable now) the same value, to simulate that in
the same millisecond, it happends lots of increment.
Also I start the thread to flushcache. And the test failed:
{code}
Results :
Failed tests:
testParallelIncrementWithMemStoreFlush(org.apache.hadoop.hbase.regionserver.TestHRegion):
expected:<2000> but was:<146>
{code}
Follow is my suspect：
Maybe it is because the increment read the old value（v1） from snapshot, and
write the new value（v1+1） to memstore, after this if the flush cache is still
not completed, another increment read the value also from snapshot(v1), and
write the new value(v1+1) to memstore, so the increment operation takes no
effect.
If the above is right, I think we can read the value from memstore fist for the
same timestamp(I didn't know how to), or make the timestamp to nanoTime to
decrease the probability?
> Increment data will be lost when the memstore is flushed
> --------------------------------------------------------
>
> Key: HBASE-6195
> URL: https://issues.apache.org/jira/browse/HBASE-6195
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Reporter: Xing Shi
> Assignee: ShiXing
> Fix For: 0.96.0, 0.94.1
>
> Attachments: 6195-trunk-V7.patch, 6195.addendum,
> HBASE-6195-trunk-V2.patch, HBASE-6195-trunk-V3.patch,
> HBASE-6195-trunk-V4.patch, HBASE-6195-trunk-V5.patch,
> HBASE-6195-trunk-V6.patch, HBASE-6195-trunk.patch
>
>
> There are two problems in increment() now:
> First:
> I see that the timestamp(the variable now) in HRegion's Increment() is
> generated before got the rowLock, so when there are multi-thread increment
> the same row, although it generate earlier, it may got the lock later.
> Because increment just store one version, so till now, the result will still
> be right.
> When the region is flushing, these increment will read the kv from snapshot
> and memstore with whose timestamp is larger, and write it back to memstore.
> If the snapshot's timestamp larger than the memstore, the increment will got
> the old data and then do the increment, it's wrong.
> Secondly:
> Also there is a risk in increment. Because it writes the memstore first and
> then HLog, so if it writes HLog failed, the client will also read the
> incremented value.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
