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 20:38:25 GMT

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

Bryan Duxbury commented on HBASE-514:

> Why are we not allows searching w/ 'key'? Why are we using the earliest key?
If there are any keys in the candidateKeys, then we want to start with the first one in there.
If there are keys in candidateKeys, then they are guaranteed to be <= the search row's
key. We need to start as early as possible because we also want to scan over regions where
there might be deletes for candidates from earlier on. If we always just started at the search
row, we wouldn't know if earlier candidate keys had been suppressed later on. 

> Regards your strip timestamp method, creating a new HSK is safest but do you need to
create a new instance? (Could setVersion on current hsk).
I have no problem changing this method. Figuring cut down on object creations?

> Do you think candidateKeys size could be large or the aggregate of the values would blow
memory? Do we have to carry the values? Can we get away with just yes no on whether a delete
value or not?
We do not carry the values, just the keys. If the keys happen to be very large, then there
is the possibility of using up lots of memory. Moreover, the idea is that when we encounter
a delete, we'll use that event to remove the key that corresponds to it from the set of candidate
keys. The candidate keys set should grow and shrink as we find and entertain more candidate

> In this code: ...
Actually, in this case, we're iterating through the map backwards, so once we've found one
row that survives the whole way, then we've found the closest row already, and should stop

> Is the return premature in below or is rationale that because mapfiles are sorted, we
look at first one and its last key is 'highest' for this store?

> 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
>             Fix For: 0.1.0
>         Attachments: 514-0.1-v2.patch, 514-0.1.patch, 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