[
https://issues.apache.org/jira/browse/HBASE-29706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18048878#comment-18048878
]
Hudson commented on HBASE-29706:
--------------------------------
Results for branch branch-2.5
[build #763 on
builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763/]:
(x) *{color:red}-1 overall{color}*
----
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 jdk17 hadoop3 checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 jdk17 hadoop 3.2.4 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 jdk17 hadoop 3.3.5 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 jdk17 hadoop 3.3.6 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk17 hadoop 3.4.1 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 source release artifact{color}
-- Something went wrong with this stage, [check relevant console
output|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763//console].
(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console
output|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/763//console].
> Modify table with lazy mode should pass if coprocessors have not changed
> ------------------------------------------------------------------------
>
> 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
> Assignee: Aman Poonia
> Priority: Major
> Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.6.5, 2.5.14
>
>
> 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)
