[
https://issues.apache.org/jira/browse/HBASE-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507536#comment-13507536
]
stack commented on HBASE-7247:
------------------------------
Moving znode from OPENING to OPENING or CLOSING to CLOSING ensuring the
sequence numbers are as we expect is how we check we still have 'ownership' of
the region before we go about making alterations in the filesystem. The
callback the master gets when we 'update' the znode is used to flag the master
that the region server is still 'alive' and working on the opening so the
master updates its opening timer when it gets the callback.
It is imperfect in that we could lose the lease between the check and the fs
operation.
Alternatives would be to remove this mechanism and instead just rely on our
getting a callback if the znode is taken from us? This would happen in another
thread. Would have to be watching. This would seem to coarser than what we
currently have widening the window during which we could do fs operations on a
region though we've lost ownership. Master would not get notification that a
region server is opening a region only its taking longer than usual.
Any other suggestions?
> 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
>
> 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
