Return-Path: X-Original-To: apmail-hbase-user-archive@www.apache.org Delivered-To: apmail-hbase-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8EE569E5A for ; Thu, 8 Mar 2012 16:49:11 +0000 (UTC) Received: (qmail 37990 invoked by uid 500); 8 Mar 2012 16:49:09 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 37956 invoked by uid 500); 8 Mar 2012 16:49:09 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 37935 invoked by uid 99); 8 Mar 2012 16:49:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Mar 2012 16:49:09 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of saint.ack@gmail.com designates 209.85.220.169 as permitted sender) Received: from [209.85.220.169] (HELO mail-vx0-f169.google.com) (209.85.220.169) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Mar 2012 16:49:04 +0000 Received: by vcbfk14 with SMTP id fk14so688130vcb.14 for ; Thu, 08 Mar 2012 08:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=BiLv/hPh2jy4jDW7msHGSdKeJmJdCeDWe9PiWfM2s0s=; b=fHidamghfYrXaofOPc/dNVkEszrPNjf7LufNVga8nyJi2QxYY78EeCOcAz14hsCDid V9azEHdZ2TgOYaMCKDJsPNhrj63jI8MDDMY0iDQkF+1u/FXIsIg3uvm2e0HzMbu8Mbtq pv+Bt7e+rQNkQE2P29UT/uFmgNkpQ3Yn/eumcUdJ+UnViMUhiWwbHlA0yIKuoAKI8tFC wUUhU3ofmcxeRTDWdjyFZdqP5oyD2uuXZUI3GhXZpA/NzIr0c9UMh/27Ugv/sQ+6GWvl ruddmwlscrCswJo/rSID1hHYCancylOiz4Sta0GMk28AAKGXt3BuFrWqsXYJRCNaUhbJ uKtA== MIME-Version: 1.0 Received: by 10.52.178.40 with SMTP id cv8mr11111390vdc.82.1331225323492; Thu, 08 Mar 2012 08:48:43 -0800 (PST) Sender: saint.ack@gmail.com Received: by 10.220.149.129 with HTTP; Thu, 8 Mar 2012 08:48:43 -0800 (PST) In-Reply-To: <460ED1013765BD4A92CDA53C2082DCC68DD8D414@EXMDB02.org.aalto.fi> References: <460ED1013765BD4A92CDA53C2082DCC68DD8D414@EXMDB02.org.aalto.fi> Date: Thu, 8 Mar 2012 08:48:43 -0800 X-Google-Sender-Auth: 1mKwzhAbQ9AVNA90aOJenMnG7ac Message-ID: Subject: Re: HTable.getEndKeys() returning empty results From: Stack To: user@hbase.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Mar 8, 2012 at 8:25 AM, de Souza Medeiros Andre wrote: > Hi all, > > Has someone had problems with HTable.getEndKeys() method? In my application it returns an array of byte[], but the first (and only) byte[] is empty, so essentially it's telling me that the (single) region has no end key. > > The table has 3 rows and I'm running standalone HBase 0.90.4 CDH3u3 on my local machine. Moreover, the call getEndKeys() is executed immediately after I put rows in the table. > > Do I need to wait until the .META. table gets updated with the regions' end row keys? > Does HTable.getEndKeys() work only in a fully distributed mode? > Is there any other way of getting the last row in a table? (this is my objective after all) > An empty byte array is the last key in a table of one region only. An hbase table uses empty byte array as both the start and end row signifier as per the bigtable paper (I don't see this explicitly called out in the reference guide but I'm probably not looking in right place). St.Ack