hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jingcheng Du (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12433) Coprocessors not dynamically reordered when reset priority
Date Tue, 11 Nov 2014 10:05:35 GMT

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

Jingcheng Du commented on HBASE-12433:

Hi all, found the issues.
if an online modifying table is allowed and that table is modified online, its regions will
be reassigned, but this assignment is asynchronous, you could see the code in TableEventHandler.process(),
the reOpenAllRegions(hris) will invoke the BulkAssigner.bulkOpen (actually here the implementation
BulkReopen is used).
if (eventType.isOnlineSchemaChangeSupported() && this.masterServices.
          tableName, ZooKeeperProtos.Table.State.ENABLED)) {
        if (reOpenAllRegions(hris)) {
          LOG.info("Completed table operation " + eventType + " on table " +
        } else {
          LOG.warn("Error on reopening the regions");

Whether the assignment is asynchronous depends on the implementation of the method waitUntilDone(timeout).
In the BulkReopen, this method directly returns true without any waiting. Until the region
is reopened, the order won't be changed.
So do we need to re-implement the method BulkReopen.waitUtilDone(timeout) here for this case?
Any ideas, thanks.

> Coprocessors not dynamically reordered when reset priority
> ----------------------------------------------------------
>                 Key: HBASE-12433
>                 URL: https://issues.apache.org/jira/browse/HBASE-12433
>             Project: HBase
>          Issue Type: Bug
>          Components: Coprocessors
>    Affects Versions: 0.98.7
>            Reporter: James Taylor
> When modifying the coprocessor priority through the HBase shell, the order of the firing
of the coprocessors wasn't changing. It probably would have with a cluster bounce, but if
we can make it dynamic easily, that would be preferable.

This message was sent by Atlassian JIRA

View raw message