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] Commented: (HBASE-514) table 'does not exist' when it does
Date Fri, 14 Mar 2008 00:03:24 GMT

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

Bryan Duxbury commented on HBASE-514:

In looking at the code, I've found one further problem with the way its original implemented.
In HStore#getRowKeyAtOrBefore, if the Memcache returns a non-null key, then we will automatically
use that without looking in the mapfiles at all. This means that until there is a flush, things
are fine. However, as soon as the memcache flushes once, and there are some writes into memcache,
then the Memcache will return incorrect answers about the closest row. This actually seems
like it could explain difficulties with WREs because when your HBase gets reasonably large,
there will be a .META. region flush, and then you're hosed for a while.

Instead we need to take the answer the memcache gives us and merge it with the results we
get from the map files. Should be a fairly easy fix.

> 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.

View raw message