Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BA4FE6047 for ; Fri, 17 Jun 2011 00:43:39 +0000 (UTC) Received: (qmail 53883 invoked by uid 500); 17 Jun 2011 00:43:39 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 53847 invoked by uid 500); 17 Jun 2011 00:43:39 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 53839 invoked by uid 99); 17 Jun 2011 00:43:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jun 2011 00:43:39 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of yuzhihong@gmail.com designates 74.125.83.169 as permitted sender) Received: from [74.125.83.169] (HELO mail-pv0-f169.google.com) (74.125.83.169) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jun 2011 00:43:31 +0000 Received: by pvc12 with SMTP id 12so1894670pvc.14 for ; Thu, 16 Jun 2011 17:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=WkSYNjgT4PSZvN/p/0aeK/k080DGDJTBCQVlnwmQMSg=; b=aTa+yWNwtjeyBepRC0abXPZV0kE9Bu0pDRbGGKYNKN9G+TvWHKXyYDyh/GuwF4nKQD tpNbpUdla/dDeIO4+OSzkye3hvFV3oyYvXQkil8FupG8jum1YcE9eNU4m2BNw5eeJaU0 11hNP30O1TwGzm1ZcJcHGqvk8jRKxwCT+kw9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=It3D6xdWqwP0I+wAItzOF/IvJlkLcXsA4Iz8xDLg01SINqeoGUYpcrILHMxWtTz+da 3UY4XikAH37HKC2S3W/vw81n5O3Rb7zhAFOcz4J/mDfVZLgWPOzZMofjE1aT69VcaAsn H2Wi135XN/u8EHEb/mLwvS1Q9RFs7Ztl8rfhU= MIME-Version: 1.0 Received: by 10.68.6.5 with SMTP id w5mr826242pbw.15.1308271389688; Thu, 16 Jun 2011 17:43:09 -0700 (PDT) Received: by 10.68.47.202 with HTTP; Thu, 16 Jun 2011 17:43:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jun 2011 08:43:09 +0800 Message-ID: Subject: Re: HBASE 3904 From: Ted Yu To: dev@hbase.apache.org Content-Type: multipart/alternative; boundary=bcaec53ae8a073c55a04a5ddabe3 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec53ae8a073c55a04a5ddabe3 Content-Type: text/plain; charset=ISO-8859-1 Here is the scenario that Vidhyashankar will run into after HBA.createTable() is modified: HBA.createTable() takes too long to execute. Client receives Socket timeout exception. Client calls HCM.isTableAvailable() which would report inaccurate status. I want to get other developers' opinion on whether HCM.isTableAvailable() should be accurate. Thanks On Fri, Jun 17, 2011 at 5:49 AM, Ted Yu wrote: > That's my interpretation after reading it again as well. > So I will put HBA.createTable() back to being synchronous again for 3904. > Cheers > On Fri, Jun 17, 2011 at 5:46 AM, Jean-Daniel Cryans > wrote: > >> I don't want to be thick, but I don't see where in that jira the fact >> that createTable became synchronous was stated as an issue. All I see >> is that it became affected by all the other region in transitions as >> well, which is orthogonal to our discussion. >> >> J-D >> >> On Thu, Jun 16, 2011 at 2:39 PM, Ted Yu wrote: >> > https://issues.apache.org/jira/browse/HBASE-3744 has been fixed. >> > >> > FYI >> > On Fri, Jun 17, 2011 at 5:32 AM, Jean-Daniel Cryans < >> jdcryans@apache.org>wrote: >> > >> >> Can you point to the issue where Todd did the revert? >> >> >> >> Thx, >> >> >> >> J-D >> >> >> >> On Thu, Jun 16, 2011 at 2:28 PM, Ted Yu wrote: >> >> > Hi, >> >> > J-D recently expressed the idea of changing behavior of >> HBA.createTable() >> >> to >> >> > be consistent with its javadoc. >> >> > Meaning, HBA.createTable() should be synchronous. >> >> > >> >> > Todd reported an issue which resulted in reverting my changes that >> caused >> >> > HBA.createTable() to be synchronous. >> >> > >> >> > I want to see if we can reach consensus on how HBASE 3904 should be >> >> handled. >> >> > >> >> > We have 3 options: >> >> > 1. making HBA.createTable() to be synchronous in TRUNK >> >> > 2. pass initial region count in HTD >> >> > 3. add new method in HBA for synchronous table creation >> >> > >> >> > Thanks >> >> > >> >> >> > >> > > --bcaec53ae8a073c55a04a5ddabe3--