[
https://issues.apache.org/jira/browse/HBASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607244#action_12607244
]
Michaela Buergle commented on HBASE-627:
----------------------------------------
In my setting, the disabling-problem described above doesn't seem to happen now
as there is hardly any reassignment of regions anymore. So this measure
certainly decreases the probability that the error will arise. I'm not sure
however that it really solves the issue, since the underlying problem was
outdated information in .META., while HBASE-615 affects only the conditions
under which the problem occurrs. There might be other line-ups leading to this
situation.
Using HTable.isTableOnline/Offline in a loop is probably a good way to avoid
the problem. A few remarks on that:
- The "// Wait until first region is disabled" - section in
HBaseAdmin.disableTable() looks very similar. Wouldn't it make sense to use
isTableOffline() here instead?
- In both disableTable() and isTableOn-/Offline(), regions of other tables than
the requested one are checked for being on-/offline (see Description of
HBASE-627). That doesn't seem right to me. If any one of those other regions is
on-/offline by chance, there will be a wrong result.
- Shouldn't a table be either online or offline? In that case, why are there
two different functions for determining the table's state instead of using e.g.
!isTableOnline().
> Disable table doesn't work reliably
> -----------------------------------
>
> Key: HBASE-627
> URL: https://issues.apache.org/jira/browse/HBASE-627
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.2.0
> Environment: Hadoop/HBase on two nodes
> Reporter: Michaela Buergle
> Assignee: Jim Kellerman
> Priority: Critical
> Fix For: 0.2.0
>
> Attachments: disableTable31.log, disableTable5.log
>
>
> When creating a couple of tables like this:
> 1) create an empty table
> 2) disable table, add new column family, enable table
> 3) put 100 small documents into newly created column
> around once in 10 tries the disable doesn't happen.
> I have no clue as to why the table isn't disabled in the first place, but if
> this occurs, two things in HBaseAdmin.disableTable() strike me as odd:
> - after numRetries tries to wait for disabling we exit the loop; there is no
> exception or error message:
> ...
> 2008-05-14 16:19:47,903 INFO org.apache.hadoop.hbase.client.HBaseAdmin:
> Disabled table table31
> 2008-05-14 16:19:47,910 INFO org.apache.hadoop.ipc.Server: IPC Server handler
> 3 on 60000, call addColumn(table31, {name: document, max versions: 3,
> compression: NONE, in memory: false, block cache enabled: false, max length:
> 2147483647, time to live: FOREVER, bloom filter: none}) from
> XXX.XX.40.36:47116: error: org.apache.hadoop.hbase.TableNotDisabledException:
> table31
> ...
> - the scanner iterates over HRegionInfos of several tables. If any one of
> those is disabled, we also leave the loop as if the requested table had been
> disabled.
> I've had this disabling problem occur quite reliably over the last days -
> today I couldn't reproduce it, though HBase version hasn't changed. ???
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
