[
https://issues.apache.org/jira/browse/HBASE-17624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15868705#comment-15868705
]
Francis Liu commented on HBASE-17624:
-------------------------------------
{quote}
That makes sense. What you describe though seems like a general issue w/ our
assignment (and w/ having to rpc under a synchronization).
{quote}
Yes the problem can be solved either by fixing the synchronization in
assignment or in rsgroup. RSGroup is simple enough that it should be no problem
to make reads concurrent. There could be other actors accessign RSGroup so
better to make it concurrent so consumers don't have to worry about deadlock
(already too many things to worry about).
{quote}
If you can describe how what was originally in place made it so moves would
work though system tables were in transition – hbase:meta and hbase:rsgroup –
that'd help;
{quote}
In the code prior to this patch the getter methods that retrieve group
information (getRSGroup, ofTable, OfServer, etc) don't require the monitor lock
so the deadlock cycle is broken.
{quote}
how was update of zk cache and updates to hbase:rsgroup protected perviously? I
didn't see coherent guard (probably my misunderstanding). Lets fix.
{quote}
The methods that does mutations and updates to zk and hbase:rsgroup are
synchronized appropriately. Point me to where the incoherence is?
> Address late review of HBASE-6721, rsgroups feature
> ---------------------------------------------------
>
> Key: HBASE-17624
> URL: https://issues.apache.org/jira/browse/HBASE-17624
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
> Reporter: stack
> Assignee: stack
> Fix For: 2.0.0
>
> Attachments: HBASE-17624.master.001.patch,
> HBASE-17624.master.002.patch, HBASE-17624.master.003.patch,
> HBASE-17624.master.004.patch, HBASE-17624.master.005.patch,
> HBASE-17624.master.006.patch, HBASE-17624.master.007.patch,
> HBASE-17624.master.008.patch, HBASE-17624.master.009.patch,
> HBASE-17624.master.010.patch
>
>
> An internal review by [~busbey] and [~appy] turned up a bunch of good
> findings going over HBASE-6721. They found some really good stuff a guava
> type is part of our public API and concurrency in a few core classes is
> inconsistent.
> Patch coming.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
