[
https://issues.apache.org/jira/browse/HBASE-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231873#comment-13231873
]
Lars Hofhansl commented on HBASE-5569:
--------------------------------------
Reverted from 0.94 and trunk. Sigh.
A few more details:
* This has definitely something to do with
StoreScanner.{checkReseek|resetScannerStack}.
* I *always* see the DEBUG message about the StoreScanner.peek being changed.
* Removing the code for HBASE-5121 does *not* fix this problem.
* This is not related to HBASE-5568.
* The new KV on the heap is always older than the existing one (so the scanner
is going backwards in this case)! In this test the client threads assign the
timestamps, so one of them might just fall behind.
* The new KV on the head always has memstoreTS=0.
* Either the new or the old KV is a delete marker (but that might be because of
the nature of this test).
* Both testRowMutationMultiThreads and testMultiRowMutationMultiThreads have
the same problem. So this happens even for Puts and Deletes for the *same* Row,
even when they written with the same mvcc writenumber and the in the same
WALEdit.
I'll see if I can write a more deterministic test for this.
> Do not collect deleted KVs when they are still in use by a scanner.
> -------------------------------------------------------------------
>
> Key: HBASE-5569
> URL: https://issues.apache.org/jira/browse/HBASE-5569
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.94.0, 0.96.0
>
> Attachments: 5569-v2.txt, 5569.txt,
> TestAtomicOperation-output.trunk_120313.rar
>
>
> I noticed this because TestAtomicOperation.testMultiRowMutationMultiThreads
> fails rarely.
> The solution is similar to HBASE-2856, where expired KVs are not collected
> when in use by a scanner.
> ---
> What I pieced together so far is that it is the *scanning* side that has
> problems sometimes.
> Every time I see a assertion failure in the log I see this before:
> {quote}
> 2012-03-12 21:48:49,523 DEBUG [Thread-211] regionserver.StoreScanner(499):
> Storescanner.peek() is changed where before =
> rowB/colfamily11:qual1/75366/Put/vlen=6,and after =
> rowB/colfamily11:qual1/75203/DeleteColumn/vlen=0
> {quote}
> The order of if the Put and Delete is sometimes reversed.
> The test threads should always see exactly one KV, if the "before" was the
> Put the thread see 0 KVs, if the "before" was the Delete the threads see 2
> KVs.
> This debug message comes from StoreScanner to checkReseek. It seems we still
> some consistency issue with scanning sometimes :(
--
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
