[
https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534441
]
stack commented on HADOOP-1872:
-------------------------------
>From IRC a few minutes ago:
{code}
[16:00] <cutting> stack: TestCompaction worked for me with
samepatchdifferentname.patch. running again.
[16:01] <cutting> stack: taking a long time this time...
[16:01] <stack> cutting: ugh
[16:02] <cutting> i'm using 'ant test-contrib -Dtestcase=TestCompaction'
[16:05] <stack> cutting: Did it work 2nd time? (Works for me when I run it
multiple times)
[16:06] <cutting> stack: still running 2nd time
[16:06] <cutting> should i control-C?
[16:06] <stack> cutting: I suppose.
[16:06] <jim_kellerman> cutting: kill -QUIT and sending us the logs might help
[16:07] <stack> cutting: Mind retrying?
[16:07] <cutting> i gotta run right now.
[16:07] <stack> cutting: I redo it here on this ubuntu machine and it works.
[16:07] <stack> cutting: Ok. I won't commit.
{code}
> [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
> Attachments: samepatchdifferentname.patch, 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.
