hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions fail on some hosts
Date Tue, 16 Oct 2007 20:41:50 GMT

     [ 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.


Mime
View raw message