Return-Path: Delivered-To: apmail-lucene-hadoop-dev-archive@locus.apache.org Received: (qmail 74399 invoked from network); 16 Sep 2007 04:40:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Sep 2007 04:40:53 -0000 Received: (qmail 21515 invoked by uid 500); 16 Sep 2007 04:40:45 -0000 Delivered-To: apmail-lucene-hadoop-dev-archive@lucene.apache.org Received: (qmail 21485 invoked by uid 500); 16 Sep 2007 04:40:45 -0000 Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hadoop-dev@lucene.apache.org Delivered-To: mailing list hadoop-dev@lucene.apache.org Received: (qmail 21476 invoked by uid 99); 16 Sep 2007 04:40:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Sep 2007 21:40:45 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Sep 2007 04:40:52 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 3E9F4714168 for ; Sat, 15 Sep 2007 21:40:32 -0700 (PDT) Message-ID: <10404373.1189917632253.JavaMail.jira@brutus> Date: Sat, 15 Sep 2007 21:40:32 -0700 (PDT) From: "Hadoop QA (JIRA)" To: hadoop-dev@lucene.apache.org Subject: [jira] Commented: (HADOOP-1872) [hbase] TestCompaction assertions fail on some hosts In-Reply-To: <32109325.1189463909732.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on 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". > Thats single-cpu... > yep > 1GB of ram. bog standard pc. > 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.