[
https://issues.apache.org/jira/browse/HBASE-12433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209178#comment-14209178
]
Jingcheng Du commented on HBASE-12433:
--------------------------------------
Thanks [~anoopsamjohn] and [~apurtell] for the comments.
The assignment is asynchronous, after the region assignment and reopened is
finished, the coprocessors will be reordered.
I had done some testing recently,
# adding two coprocessors in the HTableDescriptor.
# put/scan/get a row.
# modify the coprocessor priority and modify the HTD online.
# put/scan/get a row again.
in the testing output, the put could get the ordered coprocessors every time.
The scan and get will get the ordered coprocessors only after the region is
reassigned (it's possible to get the unordered coprocessors in these ops,
sometimes in the testing we could get the exception NotServingRegionException:
{regionName}. is closing)..
I guess after the table is modified online, the ops might be processed
successfully before the region is marked as closing.
bq. We just need to, eventually, when the region is reopened to apply the
schema update, have the coprocessor ordering change apply.
According to the testing, the coprocessors will be reloaded/orded after the
region is reopened.
bq. I don't think James is reporting the changes have to be applied before the
admin call returns. I think he's reporting that time goes by and the changes
never seem to be applied.
Hi James, [~jamestaylor], what's the issue encountered? The coprocessors are
not reordered after a long time from the online modification? Please advise,
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
(v6.3.4#6332)
