You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Mikhail Antonov (JIRA)" <ji...@apache.org> on 2015/04/17 23:09:00 UTC

[jira] [Commented] (HBASE-11290) Unlock RegionStates

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

Mikhail Antonov commented on HBASE-11290:
-----------------------------------------

I'm thinking to resurrect this patch, as lots of time and effort seem to have been invested in that.

[~virag], [~toffer], [~apurtell] - what do you guys think? Switching to IdLock could be easier improvement here, or probably be done in subsequent patch?

What I'm thinking need to be clarified in latest version of patch is what's the eviction policy of LockCache? 

bq. We need to evict elements otherwise the map may grow unbounded. 
But we can't evict element if it's being used as a lock key, right? Perhaps we should have upper bound on number of  locks held at any time and reject new acquire() call if this limit is reached?

> Unlock RegionStates
> -------------------
>
>                 Key: HBASE-11290
>                 URL: https://issues.apache.org/jira/browse/HBASE-11290
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Francis Liu
>            Assignee: Virag Kothari
>             Fix For: 2.0.0, 1.1.0, 0.98.13
>
>         Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, HBASE-11290.draft.patch
>
>
> Even though RegionStates is a highly accessed data structure in HMaster. Most of it's methods are synchronized. Which limits concurrency. Even simply making some of the getters non-synchronized by using concurrent data structures has helped with region assignments. We can go as simple as this approach or create locks per region or a bucket lock per region bucket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)