hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francis Liu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17624) Address late review of HBASE-6721, rsgroups feature
Date Wed, 15 Feb 2017 22:29:41 GMT

    [ 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:

That makes sense. What you describe though seems like a general issue w/ our assignment (and
w/ having to rpc under a synchronization).
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). 

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; 
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. 

how was update of zk cache and updates to hbase:rsgroup protected perviously? I didn't see
coherent guard (probably my misunderstanding). Lets fix.
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,
> 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

View raw message