[
https://issues.apache.org/jira/browse/HBASE-6469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586523#comment-13586523
]
Lars Hofhansl commented on HBASE-6469:
--------------------------------------
I am not sure I like this approach.
The problem here is that the ZK state is either stuck in ENABLING or DISABLING.
A background thread checking on this does not seem to be that useful.
If a background can continue the transaction, why can't another (user
initiated) attempt to either enable or disable the table?
The expectation here is that a user won't care what care what state the table
is currently in. If a disable is triggered the result should be a disabled
table (and similar for an enable).
Can we just make so that we allow transitioning from ENABLING to both ENABLED
or DISABLED and from DISABLING to both ENABLED or DISABLED?
> Failure on enable/disable table will cause table state in zk to be left as
> enabling/disabling until master is restarted
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-6469
> URL: https://issues.apache.org/jira/browse/HBASE-6469
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.94.2, 0.96.0
> Reporter: Enis Soztutar
> Assignee: rajeshbabu
> Fix For: 0.96.0, 0.94.6
>
> Attachments: 6469-expose-force-r3.patch, HBASE-6469_2.patch,
> HBASE-6469_3.patch, HBASE-6469.patch
>
>
> In Enable/DisableTableHandler code, if something goes wrong in handling, the
> table state in zk is left as ENABLING / DISABLING. After that we cannot force
> any more action from the API or CLI, and the only recovery path is restarting
> the master.
> {code}
> if (done) {
> // Flip the table to enabled.
> this.assignmentManager.getZKTable().setEnabledTable(
> this.tableNameStr);
> LOG.info("Table '" + this.tableNameStr
> + "' was successfully enabled. Status: done=" + done);
> } else {
> LOG.warn("Table '" + this.tableNameStr
> + "' wasn't successfully enabled. Status: done=" + done);
> }
> {code}
> Here, if done is false, the table state is not changed. There is also no way
> to set skipTableStateCheck from cli / api.
> We have run into this issue a couple of times before.
--
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
