[
https://issues.apache.org/jira/browse/HBASE-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935196#action_12935196
]
stack commented on HBASE-3269:
------------------------------
This is the fix:
{code}
pynchon-432:clean_trunk stack$ svn diff
Index: src/main/ruby/hbase/admin.rb
===================================================================
--- src/main/ruby/hbase/admin.rb (revision 1038464)
+++ src/main/ruby/hbase/admin.rb (working copy)
@@ -83,7 +83,7 @@
# Disables a table
def disable(table_name)
return unless enabled?(table_name)
- @admin.disableTableAsync(table_name)
+ @admin.disableTable(table_name)
end
#----------------------------------------------------------------------------------------------
{code}
I'm just going to commit.
> HBase table truncate semantics seems broken as "disable" table is now async
> by default.
> ---------------------------------------------------------------------------------------
>
> Key: HBASE-3269
> URL: https://issues.apache.org/jira/browse/HBASE-3269
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.0
> Environment: RHEL5 x86_64
> Reporter: Suraj Varma
> Assignee: stack
> Priority: Critical
> Fix For: 0.90.0, 0.92.0
>
>
> The new async design for disable table seems to have caused a side effect on
> the truncate command. (IRC chat with jdcryans)
> Apparent Cause:
> "Disable" is now async by default. When truncate is called, the disable
> operation returns immediately and when the drop is called, the disable
> operation is still not completed. This results in
> HMaster.checkTableModifiable() throwing a TableNotDisabledException.
> With earlier versions, disable returned only after Table was disabled.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
