You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2013/08/12 23:53:48 UTC
[jira] [Commented] (HBASE-9184) Ignore zk assign event if region is
not known in transition
[ https://issues.apache.org/jira/browse/HBASE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13737408#comment-13737408 ]
stack commented on HBASE-9184:
------------------------------
+1
Nice test.
In future, if editing log lines, try and make them more terse (we don't need 'server' in these log lines for instance because what else would it be that would be writing these logs?)
Yours, St.Ack on his one man mission to make it so you don't need the scoreboard at att park to see a full hbase log line!
> Ignore zk assign event if region is not known in transition
> -----------------------------------------------------------
>
> Key: HBASE-9184
> URL: https://issues.apache.org/jira/browse/HBASE-9184
> Project: HBase
> Issue Type: Bug
> Components: Region Assignment
> Reporter: Jimmy Xiang
> Assignee: Jimmy Xiang
> Fix For: 0.98.0, 0.95.2
>
> Attachments: trunk-9184.patch
>
>
> This is a follow up of HBASE-9161. Currently, if a region is in transition, we ignore any unexpected zk assign event and log a warning. For example, a zk closing event will be ignored if the region is pending open actually. However, if the region is not in transition, we will accept such events. For events not related to split/merge, we should ignore them and log a warning too, to tighten up the region state transition. During normal operation, this (ensuring region is in transition before accepting transition related events) is fine. During master failover, this is fine as long as we don't do region transition bypass ZK. We should also make sure to watch assignment znodes after user region states are recovered, so that we don't log many such warnings.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira