[
https://issues.apache.org/jira/browse/HBASE-20498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463029#comment-16463029
]
stack commented on HBASE-20498:
-------------------------------
Hard to do test for this edge case. What was there was an 'optimization'.
Slackening the optimization so we may end up doing more work than is necessary
in some cases but this should be more correct. [~uagashe] Mind taking a look?
> [AMv2] Stuck in UnexpectedStateException
> ----------------------------------------
>
> Key: HBASE-20498
> URL: https://issues.apache.org/jira/browse/HBASE-20498
> Project: HBase
> Issue Type: Sub-task
> Reporter: stack
> Priority: Critical
> Fix For: 2.0.1
>
> Attachments: HBASE-20498.branch-2.001.patch
>
>
> Here is how we get into a stuck scenario in hbase-2.0.0RC2.
> * Assign a region. It is moved to OPENING state then RPCs the RS.
> * RS opens region. Tells Master.
> * Master tries to complete the assign by updating hbase:meta.
> * hbase:meta is hosed because I'd deployed a bad patch that blocked
> hbase:meta updates
> * Master is stuck retrying RPCs to RS hosting hbase:meta; we want to update
> our new OPEN state in hbase:meta.
> * I kill Master because I want to fix the broke patch.
> * On restart, a script sets table to be DISABLED.
> * As part of startup, we go to assign regions.
> * We skip assigning regions because the table is DISABLED; i.e. we skip the
> replay of the unfinished assign.
> * The region is now a free-agent; no lock held, so, the queued unassign that
> is part of the disable table can run
> * It fails because region is in OPENING state, an UnexpectedStateException
> is thrown.
> We loop complaining the above.
> Resolution requires finishing previous assign first, then we can disable.
> Let me try and write a test to manufacture this state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)