[
https://issues.apache.org/jira/browse/HBASE-29706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18036305#comment-18036305
]
Andrew Kyle Purtell commented on HBASE-29706:
---------------------------------------------
Yes, this seems like an important consideration. Otherwise use cases like
Phoenix cannot enjoy lazy mode for changes that should be allowed to be lazy.
What I would suggest is instead of just blocking lazy mode when coprocessors
are installed, do a before and after comparison of the table descriptor to see
if a coprocessor is added or removed. If there is no change to the list of
coprocessors, it seems we can let lazy mode go forward. If there is a change to
the coprocessor list, then the change would have to be not lazy.
> Make region reopen lazy mode for modifyTable() accessible to coprocessors
> -------------------------------------------------------------------------
>
> Key: HBASE-29706
> URL: https://issues.apache.org/jira/browse/HBASE-29706
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 3.0.0-beta-1, 2.6.4, 2.5.13
> Reporter: Viraj Jasani
> Priority: Major
>
> HBASE-25549 provides configuration to not reopen regions when user modifies
> table descriptor. However, it does not work for table with coprocessors.
> As this feature is quite helpful in general, the proposal of this Jira is to
> extend the feature to coprocessors and column family descriptor updated as
> well.
> {code:java}
> /**
> * The same as {@link #modifyTableAsync(TableDescriptor td)}, except for the
> reopenRegions
> * parameter, which controls whether the process of modifying the table
> should reopen all regions.
> * @param td description of the table
> * @param reopenRegions By default, 'modifyTable' reopens all regions,
> potentially causing a RIT
> * (Region In Transition) storm in large tables. If set
> to 'false', regions
> * will remain unaware of the modification until they
> are individually
> * reopened. Please note that this may temporarily
> result in configuration
> * inconsistencies among regions.
> * @return the result of the async modify. You can use Future.get(long,
> TimeUnit) to wait on the
> * operation to complete
> * @throws IOException if a remote or network exception occurs
> */
> Future<Void> modifyTableAsync(TableDescriptor td, boolean reopenRegions)
> throws IOException;
> {code}
> The user using this feature must be aware of the consequences of temporary
> inconsistencies of the configurations. We can also provide big warning
> message with it's usage but coprocs should be allowed to leverage the feature.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
