Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C126FD3BD for ; Mon, 28 Jan 2013 23:13:15 +0000 (UTC) Received: (qmail 79767 invoked by uid 500); 28 Jan 2013 23:13:15 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 79711 invoked by uid 500); 28 Jan 2013 23:13:15 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 79545 invoked by uid 99); 28 Jan 2013 23:13:15 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Jan 2013 23:13:15 +0000 Date: Mon, 28 Jan 2013 23:13:15 +0000 (UTC) From: "Jean-Daniel Cryans (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HBASE-7700) TestColumnSeeking is mathematically bound to fail MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Daniel Cryans updated HBASE-7700: -------------------------------------- Attachment: HBASE-7700-0.94-lazyfix.patch This patch implements the first fix aka lazy fix. It should not fail again with this. > TestColumnSeeking is mathematically bound to fail > ------------------------------------------------- > > Key: HBASE-7700 > URL: https://issues.apache.org/jira/browse/HBASE-7700 > Project: HBase > Issue Type: Bug > Affects Versions: 0.96.0, 0.94.4 > Reporter: Jean-Daniel Cryans > Assignee: Jean-Daniel Cryans > Fix For: 0.96.0, 0.94.5 > > Attachments: HBASE-7700-0.94-lazyfix.patch > > > First I'd like to say that TestColumnSeeking is a bad test. It's not documented, it's non-deterministic, it's 2 methods with almost the same code. > So in each test it populates column lists this way: > {code} > for (int i = 0; i < numberOfTests; i++) { > kvMaps[i] = new HashMap(); > columnLists[i] = new ArrayList(); > for (String column : allColumns) { > if (Math.random() < selectPercent) { > columnLists[i].add(column); > } > } > } > {code} > Since selectPercent is 50% and there are 10 columns, there's something like a 1/1024 chance that one of the column list ends up with 0 column. This is later mismanaged in the checks. First something like this will be printed out: > bq. 2013-01-28 11:50:02,200 INFO [pool-1-thread-1] regionserver.TestColumnSeeking(140): Columns: 0 Keys: 0 > Like it says, there's 0 columns so it couldn't add data. But then it still makes sure later that the data is there with this check: > {code} > assertEquals(kvSet.size(), results.size()); > {code} > Do notice that the parameters are reversed, and here the results.size() will be 0 since there are 0 columns for this test. > I see multiple ways to fix this: > - Skip tests that have 0 columns > - Change the randomness to at least have 1 column (like select 1 + 0..9 columns) > - Redo the whole unit test to not rely on randomness -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira