hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17653) HBASE-17624 rsgroup synchronizations will (distributed) deadlock
Date Thu, 16 Feb 2017 21:11:41 GMT

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

stack commented on HBASE-17653:

Thanks [~toffer]

bq. BTW you guys could've just asked me instead of trying to read my mind .

I tried: https://issues.apache.org/jira/browse/HBASE-17624?focusedCommentId=15862239&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15862239
... a few times. I should have written you direct to get your attention . Sorry about that.

bq. Same reason reads should not be blocked by mutations.

Intent seems to be a CopyOnWrite strategy.

Let me make this explicit and do a pass...  Pardon my over-enthusiasm.

> HBASE-17624 rsgroup synchronizations will (distributed) deadlock
> ----------------------------------------------------------------
>                 Key: HBASE-17653
>                 URL: https://issues.apache.org/jira/browse/HBASE-17653
>             Project: HBase
>          Issue Type: Bug
>          Components: rsgroup
>            Reporter: stack
>            Assignee: stack
> Follow-on from HBASE-17624. HBASE-17624 made it so one thread only has access to the
rsgroup administrator. In tail of HBASE-17624 [~toffer] describes scenario under which we
 may end up in a deadlock (distributed). Let me repeat [~toffer] comment...
> {code}
> Both read/write access can't be single threaded. Consider the situation:
> 1. move_rsgroup_servers is called
> 2. while #1 is happening rsgroup region is in transition (rpc thread in #1 holds monitor
> 3. while #2 is happening meta is in transition.
> Balancer tries to figure out plan for meta region tries to get monitor lock but can't.
rpc thread task won't release monitor lock since rsgroup region never gets assigned. rsgroup
region never gets assigned because it can't update meta with new state.
> There's a good chance this can be reproduce just by moving both rsgroup and meta region
onto the same RS and call move_rsgoup_servers on the same RS.
> A bunch different actors will query from group affiliation so we can't have writes block
> ....
> 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.
> ....
> The methods that does mutations and updates to zk and hbase:rsgroup are synchronized
appropriately. Point me to where the incoherence is?
> {code}
> This issue is about testing/fixing/restoring rsgroup access. Will be back.

This message was sent by Atlassian JIRA

View raw message