[
https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14504392#comment-14504392
]
Mikhail Antonov commented on HBASE-11290:
-----------------------------------------
Yeah, I think that would just work. After all, the lock names are encoded
region names..so even for cluster with 1M regions with edge case of bulk
re-assignment the cache shouldn't take more than few hundred mb of RAM, HMaster
should be able to handle it.
Alternatively, I guess we could just have wrapper class around CHM<name, lock>
with lock(), unlock() methods, but current patch would work, too (maybe as
further improvement we can limit the size of the cache and make getLock() block
if the cache is waiting for GC?)
What's funny, the length of this thread
(http://stackoverflow.com/questions/5639870/simple-java-name-based-locks/)
suggests that simple named locks aren't that simple ;)
> 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)
