You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "stack (JIRA)" <ji...@apache.org> on 2007/09/11 00:38:29 UTC
[jira] Created: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
[hbase] TestCompaction assertions fail on some hosts
----------------------------------------------------
Key: HADOOP-1872
URL: https://issues.apache.org/jira/browse/HADOOP-1872
Project: Hadoop
Issue Type: Bug
Reporter: stack
Assignee: stack
Priority: Minor
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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-1872:
--------------------------
Fix Version/s: 0.15.0
Status: Patch Available (was: Open)
Builds local. Trying against hudson. It should fail.
> [hbase] TestCompaction assertions fail on some hosts
> ----------------------------------------------------
>
> Key: HADOOP-1872
> URL: https://issues.apache.org/jira/browse/HADOOP-1872
> Project: Hadoop
> Issue Type: Bug
> Reporter: stack
> Assignee: stack
> Priority: Minor
> Fix For: 0.15.0
>
> Attachments: 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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-1872:
--------------------------
Component/s: contrib/hbase
> [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
> Priority: Minor
> Fix For: 0.15.0
>
> Attachments: 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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ 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)
Trying against hudson
> [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
> Priority: Minor
> Fix For: 0.15.0
>
> Attachments: 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.
[jira] Commented: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535525 ]
Hudson commented on HADOOP-1872:
--------------------------------
Integrated in Hadoop-Nightly #275 (See [http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Nightly/275/])
> [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.
[jira] Commented: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ 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}
stack@strutter:~/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
stack@strutter:~/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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Doug Cutting updated HADOOP-1872:
---------------------------------
Attachment: TEST-org.apache.hadoop.hbase.TestCompaction.txt
> [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, 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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "Jim Kellerman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Kellerman updated HADOOP-1872:
----------------------------------
Priority: Major (was: Minor)
> [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: 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.
[jira] Commented: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527822 ]
Hadoop QA commented on HADOOP-1872:
-----------------------------------
+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12365928/samepatchdifferentname.patch
against trunk revision r575986.
@author +1. The patch does not contain any @author tags.
javadoc +1. The javadoc tool did not generate any warning messages.
javac +1. The applied patch does not generate any new compiler warnings.
findbugs +1. The patch does not introduce any new Findbugs warnings.
core tests +1. The patch passed core unit tests.
contrib tests +1. The patch passed contrib unit tests.
Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/775/testReport/
Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/775/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/775/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/775/console
This message is automatically generated.
> [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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ 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)
> [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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-1872:
--------------------------
Attachment: testcompaction.patch
Patch to add back compaction assertions.
> [hbase] TestCompaction assertions fail on some hosts
> ----------------------------------------------------
>
> Key: HADOOP-1872
> URL: https://issues.apache.org/jira/browse/HADOOP-1872
> Project: Hadoop
> Issue Type: Bug
> Reporter: stack
> Assignee: stack
> Priority: Minor
> Attachments: 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.
[jira] Commented: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534991 ]
Doug Cutting commented on HADOOP-1872:
--------------------------------------
Here's the stack dump.
{noformat}
[junit] "main" prio=10 tid=0x0805a800 nid=0xbbe in Object.wait() [0xb7da1000..0xb7da2208]
[junit] java.lang.Thread.State: WAITING (on object monitor)
[junit] at java.lang.Object.wait(Native Method)
[junit] - waiting on <0x81428d58> (a java.util.HashMap)
[junit] at java.lang.Object.wait(Object.java:485)
[junit] at org.apache.hadoop.hbase.HRegion.waitOnRowLocks(HRegion.java:1538)
[junit] - locked <0x81428d58> (a java.util.HashMap)
[junit] at org.apache.hadoop.hbase.HRegion.close(HRegion.java:384)
[junit] at org.apache.hadoop.hbase.HRegion.close(HRegion.java:344)
[junit] at org.apache.hadoop.hbase.TestCompaction.tearDown(TestCompaction.java:55)
[junit] at junit.framework.TestCase.runBare(TestCase.java:130)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:118)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:208)
[junit] at junit.framework.TestSuite.run(TestSuite.java:203)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567)
{noformat}
No other user threads running.
> [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.
[jira] Commented: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535360 ]
Hadoop QA commented on HADOOP-1872:
-----------------------------------
+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12367835/samepatchdifferentname-v3.patch
against trunk revision r585247.
@author +1. The patch does not contain any @author tags.
javadoc +1. The javadoc tool did not generate any warning messages.
javac +1. The applied patch does not generate any new compiler warnings.
findbugs +1. The patch does not introduce any new Findbugs warnings.
core tests +1. The patch passed core unit tests.
contrib tests +1. The patch passed contrib unit tests.
Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/958/testReport/
Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/958/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/958/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/958/console
This message is automatically generated.
> [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.
[jira] Commented: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535348 ]
Doug Cutting commented on HADOOP-1872:
--------------------------------------
This test now passes reliably for me.
> [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.
[jira] Commented: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527825 ]
stack commented on HADOOP-1872:
-------------------------------
OK. I got a +1 here. Now let me go try on a 'bog standard' ubuntu box before committing.
> [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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-1872:
--------------------------
Fix Version/s: 0.16.0
Status: In Progress (was: Patch Available)
Try hudson again. Builds and passes tests locally and at home.lucene.com.
> [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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-1872:
--------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
Commited. Resolved. Thanks for help on this D.
> [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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-1872:
--------------------------
Attachment: samepatchdifferentname.patch
Giving the patch a different name. Maybe hudson will notice it then.
> [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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-1872:
--------------------------
Status: In Progress (was: Patch Available)
> [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: 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.
[jira] Updated: (HADOOP-1872) [hbase] TestCompaction assertions
fail on some hosts
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-1872:
--------------------------
Status: In Progress (was: Patch Available)
Resuming so I can resubmit. Hudson is idle. It seems to have missed my last submission.
> [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
> Priority: Minor
> Fix For: 0.15.0
>
> Attachments: 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.