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 5AF8DED9C for ; Sun, 20 Jan 2013 19:06:13 +0000 (UTC) Received: (qmail 21035 invoked by uid 500); 20 Jan 2013 19:06:13 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 20988 invoked by uid 500); 20 Jan 2013 19:06:12 -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 20979 invoked by uid 99); 20 Jan 2013 19:06:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 Jan 2013 19:06:12 +0000 Date: Sun, 20 Jan 2013 19:06:12 +0000 (UTC) From: "Ted Yu (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-3170) RegionServer confused about empty row keys 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-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558343#comment-13558343 ] Ted Yu commented on HBASE-3170: ------------------------------- The following test failure seems to be related: {code} Failed tests: testMultipleTimestampRanges[0](org.apache.hadoop.hbase.regionserver.TestSeekOptimizations): Expected and actual KV arrays differ at position 0: row1/myCF:qual0/2999/Put/vlen=0/ts=0 (length 3) vs. (length 0). Bloom=NONE, compr=NONE, Scan: all columns, row=1, maxVersions=1, lazySeek=false testMultipleTimestampRanges[1](org.apache.hadoop.hbase.regionserver.TestSeekOptimizations): Expected and actual KV arrays differ at position 0: row1/myCF:qual0/2999/Put/vlen=0/ts=0 (length 3) vs. (length 0). Bloom=ROW, compr=NONE, Scan: all columns, row=1, maxVersions=1, lazySeek=false testMultipleTimestampRanges[2](org.apache.hadoop.hbase.regionserver.TestSeekOptimizations): Expected and actual KV arrays differ at position 0: row1/myCF:qual0/2999/Put/vlen=0/ts=0 (length 3) vs. (length 0). Bloom=ROWCOL, compr=NONE, Scan: all columns, row=1, maxVersions=1, lazySeek=false testMultipleTimestampRanges[3](org.apache.hadoop.hbase.regionserver.TestSeekOptimizations): Expected and actual KV arrays differ at position 0: row1/myCF:qual0/2999/Put/vlen=0/ts=0 (length 3) vs. (length 0). Bloom=NONE, compr=GZ, Scan: all columns, row=1, maxVersions=1, lazySeek=false testMultipleTimestampRanges[4](org.apache.hadoop.hbase.regionserver.TestSeekOptimizations): Expected and actual KV arrays differ at position 0: row1/myCF:qual0/2999/Put/vlen=0/ts=0 (length 3) vs. (length 0). Bloom=ROW, compr=GZ, Scan: all columns, row=1, maxVersions=1, lazySeek=false testMultipleTimestampRanges[5](org.apache.hadoop.hbase.regionserver.TestSeekOptimizations): Expected and actual KV arrays differ at position 0: row1/myCF:qual0/2999/Put/vlen=0/ts=0 (length 3) vs. (length 0). Bloom=ROWCOL, compr=GZ, Scan: all columns, row=1, maxVersions=1, lazySeek=false {code} > RegionServer confused about empty row keys > ------------------------------------------ > > Key: HBASE-3170 > URL: https://issues.apache.org/jira/browse/HBASE-3170 > Project: HBase > Issue Type: Bug > Components: regionserver > Affects Versions: 0.89.20100621, 0.89.20100924, 0.90.0, 0.90.1, 0.90.2, 0.90.3, 0.90.4, 0.90.5, 0.90.6, 0.92.0, 0.92.1 > Reporter: Benoit Sigoure > Assignee: Devaraj Das > Priority: Critical > Fix For: 0.96.0 > > Attachments: 3170-1.patch, 3170-3.patch, 3170-v2.patch, 3170-v3.patch, 3170-v3.patch > > > I'm no longer sure about the expected behavior when using an empty row key (e.g. a 0-byte long byte array). I assumed that this was a legitimate row key, just like having an empty column qualifier is allowed. But it seems that the RegionServer considers the empty row key to be whatever the first row key is. > {code} > Version: 0.89.20100830, r0da2890b242584a8a5648d83532742ca7243346b, Sat Sep 18 15:30:09 PDT 2010 > hbase(main):001:0> scan 'tsdb-uid', {LIMIT => 1} > ROW COLUMN+CELL > \x00 column=id:metrics, timestamp=1288375187699, value=foo > \x00 column=id:tagk, timestamp=1287522021046, value=bar > \x00 column=id:tagv, timestamp=1288111387685, value=qux > 1 row(s) in 0.4610 seconds > hbase(main):002:0> get 'tsdb-uid', '' > COLUMN CELL > id:metrics timestamp=1288375187699, value=foo > id:tagk timestamp=1287522021046, value=bar > id:tagv timestamp=1288111387685, value=qux > 3 row(s) in 0.0910 seconds > hbase(main):003:0> get 'tsdb-uid', "\000" > COLUMN CELL > id:metrics timestamp=1288375187699, value=foo > id:tagk timestamp=1287522021046, value=bar > id:tagv timestamp=1288111387685, value=qux > 3 row(s) in 0.0550 seconds > {code} > This isn't a parsing problem with the command-line of the shell. I can reproduce this behavior both with plain Java code and with my asynchbase client. > Since I don't actually have a row with an empty row key, I expected that the first {{get}} would return nothing. -- 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