Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <1931850833.1250183115085.JavaMail.jira@brutus>
Date: Thu, 13 Aug 2009 10:05:15 -0700 (PDT)
From: "Erik Holstad (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.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
In-Reply-To: <802454123.1250037614841.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Erik Holstad commented on HBASE-1761:
-------------------------------------

Just some small comments on the patch:
HRegionServer.getClosestrowBefore()
1. We should probably add a family check, like the one we have in the other get//put methods.

GetClosestRowBEforeTracker.addDelete()
1. Could add a check to see if the kv is "bigger than the current candidate, if not don't add it

GetClosestRowBEforeTracker.isDeleted(KeyValue, NavigableSet)
1. Could move the kvts out of the for loop, same thing with the get calls from kv, like getQualifierOffset() etc
2. The line under //check column is a little bit long

The only other thing I would add is to have a structure more like in the getDeleteTracker where we have to List that we merge, which I think would work,
instead of the Map<Map>. But hopefully we can remove all of this if/when we move Meta to ZooKeeper.

Other than that I think it looks really good.

Regards Erik


> 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-v2.patch, 1761-v3.patch, 1761-v4.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.