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 Thu, 13 Mar 2008 21:58:24 GMT

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

Bryan Duxbury commented on HBASE-514:

I've been able to pretty easily fix the problem in the Memcache. However, I think I've hit
something of an algorithmic snag when it comes to sorting out the closest row in the store

The problem lies in the fact that there's no guarantee newer store files are written with
data that comes after data in older store files. For instance, a very recent store file could
have data written from 10 minutes ago, but a store file written 10 minutes ago could have
data timestamped an hour in the future. This means that you don't just need to check every
store file for what it thinks is the closest matching row. You actually have to ask every
store file what it thinks and then check it against *every other store file* to make sure
it isn't deleted! Basically, figuring out the closest row with the current strategy is n^2
where n is the number of store files. 

Maybe there's a better strategy to investigate. Perhaps if we ask every store file what it
thinks the best candidate is, then we sort the results by row, and then scan all the store
files from the first candidate to the last candidate, noting any deletes as we go, and then
ultimately choosing the maximum row remaining in that list. Would that actually even help?

> 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