[
https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HADOOP-1872:
--------------------------
Attachment: samepatchdifferentname-v2.patch
Looking at hung thread, I'm guessing its because assertion is still failing (1
of 4 times); the assertion was in middle of a batch update so row lock was
never cleaned up by a commit (or abort). This patch only addresses that
issue....
> [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-v2.patch,
> 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.
