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 3D692D73B for ; Tue, 18 Dec 2012 22:50:14 +0000 (UTC) Received: (qmail 5936 invoked by uid 500); 18 Dec 2012 22:50:13 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 5867 invoked by uid 500); 18 Dec 2012 22:50:13 -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 5806 invoked by uid 99); 18 Dec 2012 22:50:13 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Dec 2012 22:50:13 +0000 Date: Tue, 18 Dec 2012 22:50:13 +0000 (UTC) From: "Hudson (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-7377) Clean up TestHBase7051 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-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13535420#comment-13535420 ] Hudson commented on HBASE-7377: ------------------------------- Integrated in HBase-TRUNK #3635 (See [https://builds.apache.org/job/HBase-TRUNK/3635/]) HBASE-7377 Clean up TestHBase7051 (Revision 1423674) Result = FAILURE gchanan : Files : * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHBase7051.java > Clean up TestHBase7051 > ---------------------- > > Key: HBASE-7377 > URL: https://issues.apache.org/jira/browse/HBASE-7377 > Project: HBase > Issue Type: Improvement > Affects Versions: 0.94.3, 0.96.0 > Reporter: Gregory Chanan > Assignee: Gregory Chanan > Priority: Minor > Fix For: 0.96.0, 0.94.4 > > Attachments: HBASE-7377-94.patch, HBASE-7377-trunk.patch > > > TestHBase7051 tests a race condition between checkAndPuts and puts, but is hard to follow and verify correctness on for a few reasons: > - there are no comments and the steps of the test are numbers > - there are variables that are read/written on different threads with no synchronization/volatile (e.g. checkAndPutCompleted). This may be okay depending on the other synchronization, but hard to verify. > - the worker threads are not checked for exceptions. This may also be okay if it is not possible for the test to succeed if exceptions are thrown, but hard to verify. > - The test seems to work, but I'm not sure if it's for the reasons expected. HBASE-7051 is recreated if the following steps occur: > 1) Put releases row lock (where we are now) > 2) CheckAndPut grabs row lock and reads the value prior to the put (10) > because the MVCC has not advanced > 3) Put advances MVCC > On Step 1 the test does the following: > {code} > latch.await(); > {code} > which waits for the checkAndPut to grab the row lock: > {code} > latch.countDown(); > return super.getLock(lockid, row, waitForLock); > {code} > But now we haven't really done anything to guarantee the race we want: the put will try to advance the MVCC and the checkAndPut will try to read and either could win, when we really want the checkAndPut read to win. > Luckily, the put actually waits before advancing its MVCC, but only because it happens to fall through to the next case in the if: > {code} > if (count == 2) { > try { > putCompleted = true; > super.releaseRowLock(lockId); > latch.await(); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > if (count == 3) { > super.releaseRowLock(lockId); > try { > Thread.sleep(1000); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > latch.countDown(); > } > {code} > which happens to sleep. I doubt this is intentional. Also, there are multiple latch.countDown calls even though the latch is initialized to 1. -- 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