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

stack commented on HADOOP-1872:
-------------------------------

Just tried it on following:

{code}
[EMAIL PROTECTED]:~/hadoop/src/contrib/hbase$ more /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 1.60GHz
stepping        : 6
cpu MHz         : 600.000
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat 
clflush dts acpi mmx fxsr sse sse2 ss tm pbe up est tm2
bogomips        : 1197.84
clflush size    : 64

[EMAIL PROTECTED]:~/hadoop/src/contrib/hbase$ more /etc/issue
Ubuntu 7.04 \n \l
{code}

TestCompaction passed.

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

Reply via email to