[
https://issues.apache.org/jira/browse/HBASE-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-3311:
-------------------------
Attachment: 3311.txt
Here's a patch that comments out the PENDING_CLOSE messing in
TestMasterFailover. As is, it makes no sense. Patch also adds more assertions
to TestMasterFailover -- e.g. after wait on RIT, verify RIT is actually empty
-- and changes name of the isInitialized data member to initialized. It will
also catch null data passed to handleRegion in AM and I improved comments
around the catches in AM#unassign enunciating presumptions around how the
recovery of a failed rpc close is expected to happen.
> Addendum patch on HBASE-3298 broke buid
> ---------------------------------------
>
> Key: HBASE-3311
> URL: https://issues.apache.org/jira/browse/HBASE-3311
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Fix For: 0.90.0
>
> Attachments: 3311.txt
>
>
> Our addendum patch on HBASE-3298 removed reassign if an unassign failed; it
> makes no sense doing an assign on failed unassign -- it makes for
> double-assign (at least, reasoning through the possible failures, i can't
> find case where we'd want to assign on failed unassign). Well,
> TestMasterFailover depended on this behavior. Its the test that exercises
> all of this zk stuff. It tries its best to manufacture messy scenarios. One
> scenario adds a PENDING_CLOSE but it doesn't have an associated server. A
> null server was returning a 'false' when we tried to do the close rpc which
> would fall into the since removed reassign code -- which would pick up a
> server, and the test would go on to succeed.
> Removing reassign on unassign broke this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
