[
https://issues.apache.org/jira/browse/HBASE-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510697#comment-13510697
]
nkeywal commented on HBASE-7247:
--------------------------------
bq. On the 'post_region_open', IIRC, a bunch of these tickleOpenings were added
because we saw issues... in this case, an update of .META. that went in though
we'd lost ownership of the region.
Implicitly, it means we still have a race condition here, just that the
probability is quite low.
bq. Stepping back (after looking at code), could we drop the notion that a
master can intercede and assign a region elsewhere because it is proceeding too
slow on a particular region in the name of simplifying the region open handling
interaction? There would be less noise in the logs and less states to deal with.
It would be a huge simplification imho. It's worth trying, I would say. It
actually makes sense to do it now, because once the current trunk code will be
production proven, touching it will be scarier.
bq. Do we fail the open if the following break happens?
Yes, because updateMeta will return false.
bq. We have to call the + zkw.sync(node); ? We always did that? We are doing
the sync just to read the old znode value? Do we have to? Could we operate w/
stale read?
Well, we want to be sure that no one else wrote anything. It's often overkill,
because we're going to write the znode immediately after, so the sync will
occur anyway during the write, as we check the versions during the write. And
it's expensive. So there is likely some room for improvement here as well
actually.
bq. HRegion region = this.rsServices.getFromOnlineRegions(encodedName);
We don't do anything here actually. We do a get, if the region is in the list,
'region' will not be null and that's it. This variable is set later but not
read in between. I can raise an error if it's in the list? Hopefully it won't
break anything (famous last words)
> Assignment performances decreased by 50% because of
> regionserver.OpenRegionHandler#tickleOpening
> ------------------------------------------------------------------------------------------------
>
> Key: HBASE-7247
> URL: https://issues.apache.org/jira/browse/HBASE-7247
> Project: HBase
> Issue Type: Improvement
> Components: master, Region Assignment, regionserver
> Affects Versions: 0.96.0
> Reporter: nkeywal
> Assignee: nkeywal
> Priority: Critical
> Fix For: 0.96.0
>
> Attachments: 7247.v1.patch
>
>
> The regionserver.OpenRegionHandler#tickleOpening updates the region znode as
> "Do this so master doesn't timeout this region-in-transition.".
> However, on the usual test, this makes the assignment time of 1500 regions
> goes from 70s to 100s, that is, we're 50% slower because of this.
> More generally, ZooKeper commits to disk all the data update, and this takes
> time. Using it to provide a keep alive seems overkill. At the very list, it
> could be made asynchronous.
> I'm not sure how necessary these updates are required (I need to go deeper in
> the internal, feedback welcome), but it seems very important to optimize
> this... The trival fix would be to make this optional.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
