[
https://issues.apache.org/jira/browse/HBASE-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083892#comment-13083892
]
Ted Yu commented on HBASE-1730:
-------------------------------
Nice work. In the future, please use https://reviews.apache.org for code review.
Is the following needed in HbaseObjectWritable.java where Serializable is
handled already:
{code}
+ addToMap(Pair.class, code++);
{code}
Please remove log for debugging or change it to LOG.debug():
{code}
+ LOG.info("======== in assignment manager");
{code}
{code}
+ RegionState regionState = regionsInTransition.get(hri.getEncodedName());
+ if (!regionsToReopen.isEmpty()) {
+ regionsToReopen.remove(regionState.getRegion().getEncodedName());
+ }
new ClosedRegionHandler(this.master, this, hri).process();
{code}
Should regionsToReopen.remove() call be placed inside
ClosedRegionHandler.process() (toward the end)?
And why use regionState.getRegion().getEncodedName() where hri.getEncodedName()
gives the same value ?
{code}
+ int waitTime = this.master.getConfiguration().getInt(
+ "hbase.bulk.reopen.waitafter.reopen", 0);
{code}
Do we need to retrieve the wait time every time in this method ? A better name
for the knob is hbase.bulk.waitbetween.reopen
> Near-instantaneous online schema and table state updates
> --------------------------------------------------------
>
> Key: HBASE-1730
> URL: https://issues.apache.org/jira/browse/HBASE-1730
> Project: HBase
> Issue Type: Improvement
> Reporter: Andrew Purtell
> Assignee: stack
> Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 1730-v2.patch, 1730-v3.patch, 1730.patch,
> HBASE-1730.patch
>
>
> We should not need to take a table offline to update HCD or HTD.
> One option for that is putting HTDs and HCDs up into ZK, with mirror on disk
> catalog tables to be used only for cold init scenarios, as discussed on IRC.
> In this scheme, regionservers hosting regions of a table would watch
> permanent nodes in ZK associated with that table for schema updates and take
> appropriate actions out of the watcher. In effect, schema updates become
> another item in the ToDo list.
> {{/hbase/tables/<table-name>/schema}}
> Must be associated with a write locking scheme also handled with ZK
> primitives to avoid situations where one concurrent update clobbers another.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
