hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-514) table 'does not exist' when it does
Date Fri, 14 Mar 2008 20:02:24 GMT

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

stack commented on HBASE-514:

This complicated patch is missing commit message.

I like the way you removed it from HRegionInterface and removed ts.  Should it be package
private in HRegion?

HashSet is not used in HStore

Why are we not allows searching w/ 'key'?  Why are we using the earliest key?

      // we want the earliest possible to start searching from                           
                                                                    |       }            
      HStoreKey search_key = candidateKeys.isEmpty() ?                                   
                                                                    |     }              
        new HStoreKey(key) : new HStoreKey(candidateKeys.first().getRow());     

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

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?

Whas happening here?
          if (found_key.getRow().compareTo(key) <= 0) {
            if (HLogEdit.isDeleted(tailMap.get(found_key))) {

Deletes cells only delete cells of same r/c/ts combo.  Here you are deleting any key that
has same r/c without regard for ts -- including cells newer than the found_key.  Is that intentional?
(Happens in two places)

Incomplete comment: +        // empty. examine all the keys of the

In this code:

              // if the last row we found a candidate key for is different than
              // the row of the current candidate, we can stop looking.
              if (lastRowFound != null && !lastRowFound.equals(thisKey.getRow()))

Why break, why not keeping moving forward till we get even closer to the passed in key?

Remove commented out code.

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?
        if (finalKey.getRow().compareTo(row) < 0) {

Unit tests in branch all test.  I ran a randomWrite -- thinking randomWriting would exercise
this patch --  PE with 4 clients and it succeeded (8 clients OOME'd though heap of 1.6G).
 Means that you haven't broken anything it seems.

> 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