hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Duxbury (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (HBASE-514) table 'does not exist' when it does
Date Thu, 13 Mar 2008 18:48:25 GMT

    [ https://issues.apache.org/jira/browse/HBASE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578441#action_12578441
] 

bryanduxbury edited comment on HBASE-514 at 3/13/08 11:48 AM:
---------------------------------------------------------------

I'm not sure if this is the root or even part of the problem, but looking back at the code
I wrote for getClosestRowBefore, the Memcache branch of the code isn't correct. It's pretty
close, but I can envision some scenarios where it might produce bad results.

 * internalGetRowKeyAtOrBefore doesn't take into account potentially deleted cells. This probably
isn't a big issue when dealing with region location stuff, but you never know. 
 * The check at the end of the tailMap branch of code in internalGetRowKeyAtOrBefore didn't
make sure that the found row was still a match to the row we're searching for, meaning that
in situations when the timestamp never matched for the found row but there were following
rows, if the first following row's timestamp was less than the search timestamp, you'd get
that row. Note that this means you'd actually get the first row AFTER the row you were looking
for, which is the wrong behavior.
 * The handling of the headMap branch of internalGetRowKeyAtOrBefore is potentially incorrect.
I assumed that the last cell in the headmap would contain the row we're looking for, but again
don't check for possibly deleted cells. This means you could potentially get a row key for
a region that had been deleted, say after a region split gets finalized in META. 

I'll whip up a patch to address these problems at least, so that we can feel a little more
confident that it's doing the right thing.

      was (Author: bryanduxbury):
    I'm not sure if this is the root or even part of the problem, but looking back at the
code I wrote for getClosestRowBefore, the Memcache branch of the code isn't correct. It's
pretty close, but I can envision some scenarios where it might produce bad results.

 1. internalGetRowKeyAtOrBefore doesn't take into account potentially deleted cells. This
probably isn't a big issue when dealing with region location stuff, but you never know. 
 1. The check at the end of the tailMap branch of code in internalGetRowKeyAtOrBefore didn't
make sure that the found row was still a match to the row we're searching for, meaning that
in situations when the timestamp never matched for the found row but there were following
rows, if the first following row's timestamp was less than the search timestamp, you'd get
that row. Note that this means you'd actually get the first row AFTER the row you were looking
for, which is the wrong behavior.
 1. The handling of the headMap branch of internalGetRowKeyAtOrBefore is potentially incorrect.
I assumed that the last cell in the headmap would contain the row we're looking for, but again
don't check for possibly deleted cells. This means you could potentially get a row key for
a region that had been deleted, say after a region split gets finalized in META. 

I'll whip up a patch to address these problems at least, so that we can feel a little more
confident that it's doing the right thing.
  
> table 'does not exist' when it does
> -----------------------------------
>
>                 Key: HBASE-514
>                 URL: https://issues.apache.org/jira/browse/HBASE-514
>             Project: Hadoop HBase
>          Issue Type: Bug
>          Components: client
>    Affects Versions: 0.16.0
>            Reporter: stack
>         Attachments: region-v2.patch
>
>
> This one I've seen a few times.  In hql, I do show tables and it shows my table.  I then
try to do a select against the table and hql reports table does not exist.  Digging, whats
happening is that the getClosest facility is failing to find the first table region in the
.META. table.  I hacked up a region reading tool -- attached (for 0.1 branch) -- and tried
it against but a copy and the actual instance of the region and it could do the getClosest
fine.  I'm pretty sure I restarted the HRS and when it came up again, the master had given
it again the .META. and again was failing to find the first region in the table (Looked around
in server logs and it seemed 'healthy').

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message