hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HBase Review Board (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3112) Enable and disable of table needs a bit of loving in new master
Date Tue, 09 Nov 2010 05:18:13 GMT

    [ https://issues.apache.org/jira/browse/HBASE-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929960#action_12929960

HBase Review Board commented on HBASE-3112:

Message from: stack@duboce.net

bq.  On 2010-11-08 17:04:25, Jonathan Gray wrote:
bq.  > I can live without the state-checking methods in ZKTable but it's fine, no big deal
as is.
bq.  > 
bq.  > Only issue is that we're hitting ZK on each assign().
bq.  > 
bq.  > Otherwise, if tests are passing and it's working for you up on cluster, I'm +1 on
bq.  > 
bq.  > If you add async/sync support, let's be sure to nail the javadoc.

I want the state-checking methods to flag bad state transitions.

On hitting zk on each assign, pardon me, I didn't grok what you were on about when you talked
this up earlier.  I get it now.  Will fix.

Tests are failing because I changed sematics; disable/enable are now async where before they
were sync.  Will do your suggestion of creating a sync version if only to make tests pass
(should only be for use of tests).

bq.  On 2010-11-08 17:04:25, Jonathan Gray wrote:
bq.  > trunk/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java, line 447
bq.  > <http://review.cloudera.org/r/1187/diff/3/?file=16953#file16953line447>
bq.  >
bq.  >     why describe 'enabling' state in our client API?  do we let out 'enabling' at
all anywhere?
bq.  >     
bq.  >     and do we need to make mention that if it seems to never finish, this method
should be retried?

ok.  removed mention of states.

bq.  On 2010-11-08 17:04:25, Jonathan Gray wrote:
bq.  > trunk/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java, line
bq.  > <http://review.cloudera.org/r/1187/diff/3/?file=16955#file16955line659>
bq.  >
bq.  >     isTableDisabling is actually a ZK read rather than checking in-memory state.
 Should be move enabling/disabling to in-memory state as well?  I'm not sure it's a good idea
to have to read from ZK on every assign() call, especially for something as rare as disabling.

Will fix in next patch.

- stack

This is an automatically generated e-mail. To reply, visit:

> Enable and disable of table needs a bit of loving in new master
> ---------------------------------------------------------------
>                 Key: HBASE-3112
>                 URL: https://issues.apache.org/jira/browse/HBASE-3112
>             Project: HBase
>          Issue Type: Bug
>            Reporter: stack
>            Assignee: stack
>            Priority: Critical
>             Fix For: 0.90.0
>         Attachments: 3112-v2.txt, 3112-v3.txt, 3112.txt
> The tools are in place to do a more reliable enable/disable of tables.  Some work has
been done to hack in a basic enable/disable but its not enough -- see the test avro/thrift
tests where a disable/enable/disable switchback can confuse the table state (and has been
disabled until this issue addressed).
> This issue is about finishing off enable/disable in the new master.   I think we need
to add to the table znode an enabling/disabling state rather than have them binary with a
watcher that will stop an enable (or disable) starting until the previous completes (Currently
we atomically switch the state though the region close/open lags -- some work in enable/disable
handlers helps in that they won't complete till all regions have transitioned.. but its not
> Need to add tests too.
> Marking issue critical bug because loads of the questions we get on lists are about enable/disable

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message