Thanks a lot, Stack. You explained me very well. No, I'm not seeing the issue till now.
**************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stack Sent: Tuesday, December 21, 2010 11:33 PM To: [email protected]; [email protected] Subject: Re: Query on getFirstMetaRegionForRegion() in RegionManager.java;Very Intersesting logic and unusual at same time. On Mon, Dec 20, 2010 at 10:32 PM, Mohit <[email protected]> wrote: > I call it static assignment, i.e. before putting it into regionInTransistion > and before load factor actually being considered. > > Correct me if I'm wrong, > Sounds right. > This static assignment is based on the byte comparison result, whichever > meta region entry in onlineMetaRegions is closest but less than the supplied > user region value(computed byte) is returned, Am' I right on this? And why > such a design strategy? > Entries in .META. are stored sorted. > Ok, now, if say during region assignment , that particular Region Server > i.e. RS1 which hosts the meta region containing the above made entry is > loaded(or say at that time RS2 while sending empty message server report; > HMaster in turn replied with message MSG_REGION_OPEN for this user region) > and the user region is now assigned to another server RS2, then I assume > reassignment takes place, this inconsistency which Meta Scanner reports. > Regions moving on a cluster is 'normal'. Clients recalibrate to find new locations on RS2 say. > So I need to understand how this double assignment get resolved and also > while creating table a check if table already exists prone to fail, because > it always try to get the closest meta region which could possibly be holding > that region but it may be held by another meta table/region( say hosted on > RS2). > There is only one .META. table whereever it exists. The table is not replicated. > So Even if the table exists , it will proceed ahead without any exception. > Are you seeing an issue Mohit? Thanks for looking into this. St.Ack
