[
https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HADOOP-1872:
--------------------------
Status: Patch Available (was: In Progress)
Maybe hudson will notice on this 3rd setting of 'patch available' status (For
some reason Hudson is not picking up the available patch). Just confirmed
patch still applies and tests all pass.
> [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.15.0
>
> 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.
