[
https://issues.apache.org/jira/browse/HBASE-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232383#comment-13232383
]
Lars Hofhansl commented on HBASE-5569:
--------------------------------------
TestCompaction.testMajorCompactingToNoOutput fails because the first scanner in
the test was not closed, then the compaction was done. Hence the compaction
could not remove the deleted rows, because a scanner is still (potentially)
using them.
The test is easily fixed (need to close the first scanner), but we need to
think about whether this is the design we want.
This *is* the same behavior we have with HBASE-2856 for expired rows (TTL or
too many version): If a scanner is open with an earlier readpoint these will
not be collected.
> 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-v3.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
