hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ryan rawson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1761) getclosest doesn't understand delete family; manifests as "HRegionInfo was null or empty in .META" A.K.A the BS problem
Date Sat, 15 Aug 2009 06:29:14 GMT

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

ryan rawson commented on HBASE-1761:
------------------------------------

some issues:

Store.java:1066 (in v9):

        for (Map.Entry<Long, StoreFile> e: m.entrySet()) {
          // Update the candidate keys from the current map file
          rowAtOrBeforeFromStoreFile(e.getValue(), state);
          // Early out if we can.
          if (state.hasMatch()) break;
        }


The state.hasMatch looks like so:

  boolean hasMatch() {
    if (!hasCandidate()) return false;
    return this.kvcomparator.compareRows(getCandidate(), this.targetkey) == 0;
  }


this will never return true. ever.  the targetKey is 'table,row,9999999...'.  Thus it can
never match anything ever.

So the early out doesn't work. do we want early out?  If we changed it to be 'hasMatch() {
return hasCandidate(); }', then the problem i described where
we can return a candidate from a file that doesnt have any entries for our table at all. 
That'd be bad obviously.

If we have the following hfiles in sequence order:
- hfile contains entries for tables 'a,b,c' but not 'target_table'
- hfile contains entries for 'target_table'.

then we could id something from 'c' as the candidate.  if we short circuted then we'd be in
trouble.

We might need to to constructor a concept of 'first on table' row key, but I don't know yet.

> getclosest doesn't understand delete family; manifests as "HRegionInfo was null or empty
in .META" A.K.A the BS problem
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-1761
>                 URL: https://issues.apache.org/jira/browse/HBASE-1761
>             Project: Hadoop HBase
>          Issue Type: Bug
>            Reporter: stack
>             Fix For: 0.20.0
>
>         Attachments: 1761-v10.patch, 1761-v11.patch, 1761-v2.patch, 1761-v3.patch, 1761-v4.patch,
1761-v5.patch, 1761-v6.patch, 1761-v7.patch, 1761-v9.patch, 1761.patch
>
>
> getclosestatorbefore was not converted to deal with the new delete types.  It only knows
how to process old style deletes.  Usually all is well as edits come in but its possible to
get into state where you have persisted in one file a deletefamily for all in meta and in
the file behind it, there are entries on the info family.  Since closest doesn't understand
deletefamily, it will return the Put rows only for the subsequent getfull, which knows how
to work with deletefamilies fail.
> Once this happens, table is hosed.  Seen on Bradford Stephens upload and at Powerset.
 "Fix" is flush and major compact.  Gives impression that hbase is 'delicate'.  Fixing.

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