[ 
https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HADOOP-1872:
--------------------------

    Attachment: samepatchdifferentname-v3.patch

V3 developed on home.lucene.org, the 'bog standard' ubuntu node where original 
fail was reported at head of this issue.

On this node, compactions were managing to run before test that compaction was 
needed causing assertion to fail.

Inserted addition of a bunch of new store files so even if the unpredicted 
compaction runs, there is still sufficient on-disk files for compaction at time 
of assertion test.... and so all of the subsequent assertions apply.

> [hbase] TestCompaction assertions fail on some hosts
> ----------------------------------------------------
>
>                 Key: HADOOP-1872
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1872
>             Project: Hadoop
>          Issue Type: Bug
>          Components: contrib/hbase
>            Reporter: stack
>            Assignee: stack
>             Fix For: 0.16.0
>
>         Attachments: samepatchdifferentname-v2.patch, 
> samepatchdifferentname-v3.patch, samepatchdifferentname.patch, 
> TEST-org.apache.hadoop.hbase.TestCompaction.txt, testcompaction.patch
>
>
> Changes to TestCompaction introduced in hadoop-1768 passed an hudson build 
> (#722) but reports on the hadoop irc have them failing on an an hp+ubuntu box:
> {code}
> cutting>      it's nothing fancy. /proc/cpuinfo shows "Intel(R) Pentium(R) 4 
> CPU 3.20GHz".
> <buenaventura>        Thats single-cpu...
> <cutting>     yep
> <cutting>     1GB of ram. bog standard pc.
> <cutting>     running java 5, not java 6, if that matters.
> {code}
> (Failed also w/ java6).
> The assertion that fails is count of row versions after a compaction and 
> flush.  There are usually 4 -- the 3 from stores and one that is in a flush 
> that happened 'concurrent' to the compaction -- but there can be 3 only (the 
> maximum for a column) if non-intuitively the compaction thread starts after 
> the flush finishes which can happen with certain jvm schedulers (hudson is 
> one such).
> I commented out the assertions to get the build working again.  This issue is 
> about adding them back in again in a manner that has them working on hudson 
> and the bog-standard hp+ubuntu.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to