hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5569) Do not collect deleted KVs when they are still in use by a scanner.
Date Fri, 16 Mar 2012 22:16:39 GMT

    [ https://issues.apache.org/jira/browse/HBASE-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231680#comment-13231680

Lars Hofhansl commented on HBASE-5569:

Hmm... I ran the tests (all of them - including testRowMutationMultiThreads) over 4000 times,
didn't fail.
testMultiRowMutationMultiThreads is definitely fixed (failed after a few dozen executions

There might be yet another much rarer problem with testRowMutationMultiThreads. I've never
seen it fail on the build machines, yet.

Any chance you could attach the latest logs (as zip or tar)?

Btw, this:
2012-03-14 03:14:02,146 DEBUG [Thread-51] regionserver.TestAtomicOperation$1(305): keyvalues=NONE
Exception in thread "Thread-51" 
	at junit.framework.Assert.fail(Assert.java:48)
	at junit.framework.Assert.fail(Assert.java:56)
	at org.apache.hadoop.hbase.regionserver.TestAtomicOperation$1.run(TestAtomicOperation.java:307)
2012-03-14 03:14:02,228 DEBUG [Thread-92] regionserver.TestAtomicOperation$1(279): flushing
Is just when the test detects the problem. The actual problem should be in the logs some time
before that.

> 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


View raw message