[jira] [Resolved] (HBASE-21467) Fix flaky test TestCoprocessorClassLoader.testCleanupOldJars
[
https://issues.apache.org/jira/browse/HBASE-21467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-21467.
---
Resolution: Fixed
Assignee: OrDTesters
Fix Version/s: 3.0.0
Merged. Thanks for the patch [~OrDTesters] I added you as a contributor.
> Fix flaky test TestCoprocessorClassLoader.testCleanupOldJars
>
>
> Key: HBASE-21467
> URL: https://issues.apache.org/jira/browse/HBASE-21467
> Project: HBase
> Issue Type: Bug
> Environment: Ubuntu 18.04 LTS
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T13:33:14-05:00)
> Maven home: /home/OrdTesters/apache-maven-3.5.4
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime:
> /usr/lib/jvm/jdk1.8.0_172/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-36-generic", arch: "amd64", family: "unix"
>Reporter: OrDTesters
>Assignee: OrDTesters
>Priority: Minor
> Fix For: 3.0.0
>
>
> TestCoprocessorClassLoader.testCleanupOldJars fails when run by itself.
> This can be fixed by calling CoprocessorClassLoader.getClassLoader, which
> initializes the jar file needed by testCleanupOldJars.
> Pull request: [https://github.com/apache/hbase/pull/100]
> Steps to reproduce:
> {code:java}
> git clone https://github.com/apache/hbase
> cd hbase/hbase-common
> mvn install -DskipTests -am
> mvn test -Dtest="TestCoprocessorClassLoader#testCleanupOldJars"{code}
>
> Stack trace of the failure:
>
> {code:java}
> java.io.FileNotFoundException:
> /home/OrdTesters/Java/hbase/hbase-common/target/test-data/64b7e1ae-1c34-48f7-d731-9af59256dc0a/hbase-local-dir/jars/tmp/TestCleanupOldJars.test.jar
> (Aucun fichier ou dossier de ce type)
> at java.io.FileOutputStream.open0(Native Method)
> at java.io.FileOutputStream.open(FileOutputStream.java:270)
> at java.io.FileOutputStream.(FileOutputStream.java:213)
> at java.io.FileOutputStream.(FileOutputStream.java:162)
> at
> org.apache.hadoop.hbase.util.TestCoprocessorClassLoader.testCleanupOldJars(TestCoprocessorClassLoader.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] saintstack merged pull request #100: HBASE-21467 Fix flaky test TestCoprocessorClassLoader.testCleanupOldJars
saintstack merged pull request #100: HBASE-21467 Fix flaky test TestCoprocessorClassLoader.testCleanupOldJars URL: https://github.com/apache/hbase/pull/100 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22256) Enabling FavoredStochasticBalancer on existing cluster leaves regions unassigned
[ https://issues.apache.org/jira/browse/HBASE-22256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823671#comment-16823671 ] Nikhil Bafna commented on HBASE-22256: -- [~xucang] Resubmitted the patch to invoke the QA. > Enabling FavoredStochasticBalancer on existing cluster leaves regions > unassigned > > > Key: HBASE-22256 > URL: https://issues.apache.org/jira/browse/HBASE-22256 > Project: HBase > Issue Type: Bug > Components: Balancer >Affects Versions: 2.1.3 >Reporter: Nikhil Bafna >Priority: Major > Attachments: HBASE-22256.master.001.patch, > HBASE-22256.master.001.patch, HBASE-22256.master.001.patch > > > This is related to HBASE-18349. > The test that fails corresponding to this is > TestFavoredStochasticLoadBalancer#testMisplacedRegions. When a region is > misplaced w.r.t to the favored nodes, this balancer unassigns the region and > the new RegionPlan has the source server as null leading to NPE later. This > leaves the affected regions to be unassigned after the balancer run. > This is problematic especially when moving from a different balancer to the > FavoredStochasticLoadBalancer because all regions would be "misplaced" in the > favored balancer's run. > The fix is along the lines of HBASE-18602. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] saintstack commented on a change in pull request #170: HBASE-22275 Removed deprecated getRegionInfo in HRegionLocation
saintstack commented on a change in pull request #170: HBASE-22275 Removed
deprecated getRegionInfo in HRegionLocation
URL: https://github.com/apache/hbase/pull/170#discussion_r277516685
##
File path:
hbase-client/src/main/java/org/apache/hadoop/hbase/client/MultiServerCallable.java
##
@@ -76,7 +75,7 @@ protected HRegionLocation getLocation() {
}
@Override
- public HRegionInfo getHRegionInfo() {
+ public RegionInfo getRegionInfo() {
Review comment:
You changing a public method here? Do you have to deprecate the old?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [hbase] saintstack commented on a change in pull request #170: HBASE-22275 Removed deprecated getRegionInfo in HRegionLocation
saintstack commented on a change in pull request #170: HBASE-22275 Removed
deprecated getRegionInfo in HRegionLocation
URL: https://github.com/apache/hbase/pull/170#discussion_r277516699
##
File path:
hbase-client/src/main/java/org/apache/hadoop/hbase/client/MultiServerCallable.java
##
@@ -76,7 +75,7 @@ protected HRegionLocation getLocation() {
}
@Override
- public HRegionInfo getHRegionInfo() {
+ public RegionInfo getRegionInfo() {
Review comment:
Or is this internal, private?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [hbase] saintstack commented on a change in pull request #170: HBASE-22275 Removed deprecated getRegionInfo in HRegionLocation
saintstack commented on a change in pull request #170: HBASE-22275 Removed
deprecated getRegionInfo in HRegionLocation
URL: https://github.com/apache/hbase/pull/170#discussion_r277516741
##
File path:
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ScannerCallable.java
##
@@ -366,14 +365,14 @@ public void setRenew(boolean val) {
}
/**
- * @return the HRegionInfo for the current region
+ * @return the RegionInfo for the current region
*/
@Override
- public HRegionInfo getHRegionInfo() {
+ public RegionInfo getRegionInfo() {
Review comment:
These private classes?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (HBASE-22264) Rest Server (master branch) on jdk 11 throws NoClassDefFoundError : javax/annotation/Priority
[
https://issues.apache.org/jira/browse/HBASE-22264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823667#comment-16823667
]
HBase QA commented on HBASE-22264:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
27s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
0s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
17s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
43s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
2s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
27s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}184m 8s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
56s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}204m 44s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.rsgroup.TestRSGroupsAdmin2 |
| | hadoop.hbase.snapshot.TestExportSnapshotNoCluster |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/151/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-22264 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/1298/hbase-22264.master.003.patch
|
| Optional Tests | dupname asflicense shellcheck shelldocs javac javadoc
unit xml |
| uname | Linux 44eefcc0c74b 4.4.0-143-generic #169~14.04.2-Ubuntu SMP Wed Feb
13 15:00:41 UTC 2019 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 1644d74be7 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| shellcheck | v0.4.4 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/151/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/151/testReport/ |
| Max. process+thread count | 4953 (vs. ulimit of 1) |
| modules | C: hbase-assembly . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/151/console |
| Powered by | Apache Yetus 0.9.0 http://yetus.apache.org |
This message was automatically generated.
> Rest Server (master branch) on jdk 11 throws NoClassDefFoundError :
> javax/annotation/Priority
> -
>
> Key: HBASE-22264
> URL: https://issues.apache.org/jira/browse/HBASE-22264
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22264.master.001.patch,
> hbase-22264.master.002.patch,
[GitHub] [hbase] saintstack commented on issue #158: HBASE-22047 LeaseException in Scan should be retried
saintstack commented on issue #158: HBASE-22047 LeaseException in Scan should be retried URL: https://github.com/apache/hbase/pull/158#issuecomment-485641635 Change looks good to me. What you think @allan163 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase] saintstack commented on a change in pull request #173: HBASE-22277 Removed deprecated methods from Get
saintstack commented on a change in pull request #173: HBASE-22277 Removed
deprecated methods from Get
URL: https://github.com/apache/hbase/pull/173#discussion_r277515627
##
File path: hbase-client/src/main/java/org/apache/hadoop/hbase/client/Get.java
##
@@ -260,30 +228,6 @@ public Get setTimestamp(long timestamp) {
return (Get) super.setColumnFamilyTimeRange(cf, minStamp, maxStamp);
}
- /**
- * Get all available versions.
- * @return this for invocation chaining
- * @deprecated It is easy to misunderstand with column family's max
versions, so use
- * {@link #readAllVersions()} instead.
- */
- @Deprecated
- public Get setMaxVersions() {
-return readAllVersions();
- }
-
- /**
- * Get up to the specified number of versions of each column.
- * @param maxVersions maximum versions for each column
- * @throws IOException if invalid number of versions
- * @return this for invocation chaining
- * @deprecated It is easy to misunderstand with column family's max
versions, so use
Review comment:
For sure deprecated since 2.0.0?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (HBASE-20952) Re-visit the WAL API
[
https://issues.apache.org/jira/browse/HBASE-20952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823666#comment-16823666
]
Hudson commented on HBASE-20952:
Results for branch HBASE-20952
[build #80 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20952/80/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20952/80//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20952/80//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20952/80//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Re-visit the WAL API
>
>
> Key: HBASE-20952
> URL: https://issues.apache.org/jira/browse/HBASE-20952
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Josh Elser
>Priority: Major
> Attachments: 20952.v1.txt
>
>
> Take a step back from the current WAL implementations and think about what an
> HBase WAL API should look like. What are the primitive calls that we require
> to guarantee durability of writes with a high degree of performance?
> The API needs to take the current implementations into consideration. We
> should also have a mind for what is happening in the Ratis LogService (but
> the LogService should not dictate what HBase's WAL API looks like RATIS-272).
> Other "systems" inside of HBase that use WALs are replication and
> backup Replication has the use-case for "tail"'ing the WAL which we
> should provide via our new API. B doesn't do anything fancy (IIRC). We
> should make sure all consumers are generally going to be OK with the API we
> create.
> The API may be "OK" (or OK in a part). We need to also consider other methods
> which were "bolted" on such as {{AbstractFSWAL}} and
> {{WALFileLengthProvider}}. Other corners of "WAL use" (like the
> {{WALSplitter}} should also be looked at to use WAL-APIs only).
> We also need to make sure that adequate interface audience and stability
> annotations are chosen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22211) Remove the returnBlock method because we can just call HFileBlock#release directly
[ https://issues.apache.org/jira/browse/HBASE-22211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823663#comment-16823663 ] stack commented on HBASE-22211: --- Patch LGTM. We don't always check block is not-null in tests. That is ok? Fix the checkstyle? Thanks. > Remove the returnBlock method because we can just call HFileBlock#release > directly > --- > > Key: HBASE-22211 > URL: https://issues.apache.org/jira/browse/HBASE-22211 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-22211.HBASE-21879.v01.patch, > HBASE-22211.HBASE-21879.v02.patch > > > Once HBASE-21957 get resolved, we can remove the returnBlock in this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22289) WAL-based log splitting resubmit threshold may result in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823661#comment-16823661
]
stack commented on HBASE-22289:
---
We don't do increment anymore?
SplitLogCounters.tot_wkr_preempt_task.increment();
Add note on how this fixes the issue? Into code?
Test too hard?
Thanks [~sershe]
> WAL-based log splitting resubmit threshold may result in a task being stuck
> forever
> ---
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 1.5.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22289.01-branch-2.1.patch
>
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] saintstack commented on issue #183: fix PreemptiveFastFailInterceptor clean repeatedFailuresMap issue
saintstack commented on issue #183: fix PreemptiveFastFailInterceptor clean repeatedFailuresMap issue URL: https://github.com/apache/hbase/pull/183#issuecomment-485636227 @jxxiangwen Welcome. FYI, fixing stuff, there is an associated HBase JIRA. File one over here... https://issues.apache.org/jira/projects/HBASE/issues/HBASE-22148?filter=allopenissues Shout if need help. Thanks for contributing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase] saintstack commented on issue #162: HBASE-22262 Removed deprecated methods from Filter class
saintstack commented on issue #162: HBASE-22262 Removed deprecated methods from Filter class URL: https://github.com/apache/hbase/pull/162#issuecomment-485635554 "An API needs to be deprecated for a major version before we will change/remove it." ... in "Client API compatibility" in http://hbase.apache.org/book.html#hbase.versioning.post10 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (HBASE-22003) Fix flaky test TestVerifyReplication.testHBase14905
[ https://issues.apache.org/jira/browse/HBASE-22003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HBASE-22003: - Assignee: Xinjie Yu (was: Guanghao Zhang) > Fix flaky test TestVerifyReplication.testHBase14905 > --- > > Key: HBASE-22003 > URL: https://issues.apache.org/jira/browse/HBASE-22003 > Project: HBase > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: Guanghao Zhang >Assignee: Xinjie Yu >Priority: Major > > [ERROR] Failures: > [ERROR] TestVerifyReplication.testHBase14905:246 expected:<3> but was:<2> > [ERROR] Errors: > [ERROR] > org.apache.hadoop.hbase.replication.TestVerifyReplicationCrossDiffHdfs.org.apache.hadoop.hbase.replication.TestVerifyReplicationCrossDiffHdfs > [ERROR] Run 1: TestVerifyReplicationCrossDiffHdfs.testVerifyRepBySnapshot:199 > » TestTimedOut ... > [ERROR] Run 2: > TestVerifyReplicationCrossDiffHdfs.org.apache.hadoop.hbase.replication.TestVerifyReplicationCrossDiffHdfs > » > > It failed many time when i try all ut for branch-2.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22003) Fix flaky test TestVerifyReplication.testHBase14905
[ https://issues.apache.org/jira/browse/HBASE-22003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823653#comment-16823653 ] stack commented on HBASE-22003: --- Looks great [~chetui]. Do you know how to attach a patch? Does http://hbase.apache.org/book.html#submitting.patches help? Let me add you as a contributor. Thanks. > Fix flaky test TestVerifyReplication.testHBase14905 > --- > > Key: HBASE-22003 > URL: https://issues.apache.org/jira/browse/HBASE-22003 > Project: HBase > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Major > > [ERROR] Failures: > [ERROR] TestVerifyReplication.testHBase14905:246 expected:<3> but was:<2> > [ERROR] Errors: > [ERROR] > org.apache.hadoop.hbase.replication.TestVerifyReplicationCrossDiffHdfs.org.apache.hadoop.hbase.replication.TestVerifyReplicationCrossDiffHdfs > [ERROR] Run 1: TestVerifyReplicationCrossDiffHdfs.testVerifyRepBySnapshot:199 > » TestTimedOut ... > [ERROR] Run 2: > TestVerifyReplicationCrossDiffHdfs.org.apache.hadoop.hbase.replication.TestVerifyReplicationCrossDiffHdfs > » > > It failed many time when i try all ut for branch-2.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22003) Fix flaky test TestVerifyReplication.testHBase14905
[
https://issues.apache.org/jira/browse/HBASE-22003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823650#comment-16823650
]
Xinjie Yu commented on HBASE-22003:
---
I am working on my own 2.2.0 branch and encountered the same issue when running
UT.
After some debugging, I found the timestamps of scan results are quite close.
In most cases, the timestamp diff is only 1 ms.
So I guess the root cause is:
Some put operations are performed within 1ms when running UT in a single node.
So some put may overwrite others. Finally the fetched versions count is not
expected.
I notice testVersionMismatchHBase14905 has tried to avoid such issue while
testHBase14905 not.
Attached is my patch for your guys' reference.
I have verified this test for 50 times after patching in my env, and no flaky
issue is observed.
{code:java}
diff --git
a/hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/replication/TestVerifyReplication.java
b/hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/replication/TestVerifyReplication.java
index 4ef1214e63..7d12cbcc6b 100644
---
a/hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/replication/TestVerifyReplication.java
+++
b/hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/replication/TestVerifyReplication.java
@@ -252,11 +252,12 @@ public class TestVerifyReplication extends
TestReplicationBase {
// normal Batch tests
byte[] qualifierName = Bytes.toBytes("f1");
Put put = new Put(Bytes.toBytes("r1"));
-put.addColumn(famName, qualifierName, Bytes.toBytes("v1002"));
+long ts = System.currentTimeMillis();
+put.addColumn(famName, qualifierName, ts + 1, Bytes.toBytes("v1002"));
htable1.put(put);
-put.addColumn(famName, qualifierName, Bytes.toBytes("v1001"));
+put.addColumn(famName, qualifierName, ts + 2, Bytes.toBytes("v1001"));
htable1.put(put);
-put.addColumn(famName, qualifierName, Bytes.toBytes("v1112"));
+put.addColumn(famName, qualifierName, ts + 3, Bytes.toBytes("v1112"));
htable1.put(put);
Scan scan = new Scan();
@@ -291,9 +292,9 @@ public class TestVerifyReplication extends
TestReplicationBase {
}
}
-put.addColumn(famName, qualifierName, Bytes.toBytes("v"));
+put.addColumn(famName, qualifierName, ts + 4, Bytes.toBytes("v"));
htable2.put(put);
-put.addColumn(famName, qualifierName, Bytes.toBytes("v1112"));
+put.addColumn(famName, qualifierName, ts + 5, Bytes.toBytes("v1112"));
htable2.put(put);
scan = new Scan();
{code}
> Fix flaky test TestVerifyReplication.testHBase14905
> ---
>
> Key: HBASE-22003
> URL: https://issues.apache.org/jira/browse/HBASE-22003
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
>
> [ERROR] Failures:
> [ERROR] TestVerifyReplication.testHBase14905:246 expected:<3> but was:<2>
> [ERROR] Errors:
> [ERROR]
> org.apache.hadoop.hbase.replication.TestVerifyReplicationCrossDiffHdfs.org.apache.hadoop.hbase.replication.TestVerifyReplicationCrossDiffHdfs
> [ERROR] Run 1: TestVerifyReplicationCrossDiffHdfs.testVerifyRepBySnapshot:199
> » TestTimedOut ...
> [ERROR] Run 2:
> TestVerifyReplicationCrossDiffHdfs.org.apache.hadoop.hbase.replication.TestVerifyReplicationCrossDiffHdfs
> »
>
> It failed many time when i try all ut for branch-2.2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22020) upgrade to yetus 0.9.0
[
https://issues.apache.org/jira/browse/HBASE-22020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823649#comment-16823649
]
Hudson commented on HBASE-22020:
Results for branch HBASE-22020
[build #20 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22020/20/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22020/20//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22020/20//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22020/20//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> upgrade to yetus 0.9.0
> --
>
> Key: HBASE-22020
> URL: https://issues.apache.org/jira/browse/HBASE-22020
> Project: HBase
> Issue Type: Task
> Components: build, community
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-22020-branch-1.v1.patch, HBASE-22020.0.patch,
> HBASE-22020.1.patch
>
>
> branch-1/jdk7 checkstyle dtd xml parse complaint; "script engine for language
> js can not be found"
> See parent for some context. Checkstyle references dtds that were hosted on
> puppycrawl, then on sourceforge up until ten days ago. Nightlies are failing
> for among other reasons, complaint that there is bad xml in the build...
> notably, the unresolvable DTDs.
> I'd just update the DTDs but there is a need for a js engine some where and
> openjdk7 doesn't ship with one (openjdk8 does). That needs addressing and
> then we can backport the parent issue...
> See
> https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-1/710/artifact/output-general/xml.txt
> ... which in case its rolled away, is filled with this message:
> "script engine for language js can not be found"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] jxxiangwen commented on issue #183: fix PreemptiveFastFailInterceptor clean repeatedFailuresMap issue
jxxiangwen commented on issue #183: fix PreemptiveFastFailInterceptor clean repeatedFailuresMap issue URL: https://github.com/apache/hbase/pull/183#issuecomment-485627970 > Interesting, do you use Preemptive Fail Fast feature in your production? Do you think the feature introduced in [HBASE-16388](https://issues.apache.org/jira/browse/HBASE-16388) can also solve your problem? > > Thanks. No, i am learning hbase with source code. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase] jxxiangwen commented on issue #183: fix PreemptiveFastFailInterceptor clean repeatedFailuresMap issue
jxxiangwen commented on issue #183: fix PreemptiveFastFailInterceptor clean repeatedFailuresMap issue URL: https://github.com/apache/hbase/pull/183#issuecomment-485627747 > Is there an Apache HBase JIRA associated with this PR? No, i am learning hbase with source code. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22274) Cell size limit check on append should consider cell's previous size.
[
https://issues.apache.org/jira/browse/HBASE-22274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823645#comment-16823645
]
HBase QA commented on HBASE-22274:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
37s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
35s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 18s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
25s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}174m 32s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
27s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}218m 34s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.replication.TestRegisterPeerWorkerWhenRestarting |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/148/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-22274 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/1292/HBASE-22274-master.002.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux d53815d0861c 4.4.0-143-generic #169~14.04.2-Ubuntu SMP Wed Feb
13 15:00:41 UTC 2019 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 1644d74be7 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/148/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/148/testReport/ |
| Max. process+thread count | 4790 (vs. ulimit of 1) |
| modules | C: hbase-server U:
[jira] [Commented] (HBASE-22289) WAL-based log splitting resubmit threshold may result in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823629#comment-16823629
]
HBase QA commented on HBASE-22289:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-2.1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
14s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
49s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
12s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
11s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
14s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} branch-2.1 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
15s{color} | {color:red} hbase-server: The patch generated 6 new + 17 unchanged
- 7 fixed = 23 total (was 24) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
8s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 33s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m
34s{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed =
1 total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}131m 26s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}167m 44s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Switch statement found in
org.apache.hadoop.hbase.regionserver.handler.WALSplitterHandler.process() where
one case falls through to the next case At WALSplitterHandler.java:where one
case falls through to the next case At WALSplitterHandler.java:[lines 80-83] |
| Failed junit tests | hadoop.hbase.regionserver.TestSplitLogWorker |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/149/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-22289 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12966657/HBASE-22289.01-branch-2.1.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 3c810e771730 4.4.0-143-generic #169~14.04.2-Ubuntu SMP Wed Feb
13 15:00:41 UTC 2019 x86_64 GNU/Linux |
| Build tool |
[jira] [Commented] (HBASE-22291) Fix recovery of recovered.edits files under root dir
[
https://issues.apache.org/jira/browse/HBASE-22291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823628#comment-16823628
]
HBase QA commented on HBASE-22291:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
27s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
54s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
35s{color} | {color:green} branch-1 passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} branch-1 passed with JDK v1.7.0_211 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
22s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
42s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} branch-1 passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} branch-1 passed with JDK v1.7.0_211 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
37s{color} | {color:green} the patch passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
40s{color} | {color:green} the patch passed with JDK v1.7.0_211 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
37s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
1m 45s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green} the patch passed with JDK v1.7.0_211 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}103m 24s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}128m 58s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.TestAssignmentManagerOnCluster |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/150/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-22291 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/1294/HBASE-22291.branch-1.001.patch
[GitHub] [hbase] Apache-HBase commented on issue #179: HBASE-22231 Removed unused and '*' import
Apache-HBase commented on issue #179: HBASE-22231 Removed unused and '*' import URL: https://github.com/apache/hbase/pull/179#issuecomment-485603738 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 169 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | +1 | test4tests | 0 | The patch appears to include 77 new or modified test files. | ||| _ branch-2.1 Compile Tests _ | | 0 | mvndep | 8 | Maven dependency ordering for branch | | +1 | mvninstall | 220 | branch-2.1 passed | | +1 | compile | 169 | branch-2.1 passed | | +1 | checkstyle | 178 | branch-2.1 passed | | +1 | shadedjars | 227 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 300 | branch-2.1 passed | | +1 | javadoc | 125 | branch-2.1 passed | ||| _ Patch Compile Tests _ | | 0 | mvndep | 10 | Maven dependency ordering for patch | | +1 | mvninstall | 211 | the patch passed | | +1 | compile | 178 | the patch passed | | +1 | javac | 178 | the patch passed | | +1 | checkstyle | 21 | hbase-common: The patch generated 0 new + 11 unchanged - 3 fixed = 11 total (was 14) | | +1 | checkstyle | 31 | hbase-client: The patch generated 0 new + 213 unchanged - 20 fixed = 213 total (was 233) | | +1 | checkstyle | 13 | hbase-procedure: The patch generated 0 new + 1 unchanged - 7 fixed = 1 total (was 8) | | +1 | checkstyle | 63 | hbase-server: The patch generated 0 new + 297 unchanged - 116 fixed = 297 total (was 413) | | +1 | checkstyle | 18 | hbase-mapreduce: The patch generated 0 new + 91 unchanged - 12 fixed = 91 total (was 103) | | +1 | checkstyle | 15 | hbase-it: The patch generated 0 new + 88 unchanged - 9 fixed = 88 total (was 97) | | +1 | checkstyle | 14 | hbase-rest: The patch generated 0 new + 15 unchanged - 3 fixed = 15 total (was 18) | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 228 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 446 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 340 | the patch passed | | +1 | javadoc | 127 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 160 | hbase-common in the patch passed. | | +1 | unit | 196 | hbase-client in the patch passed. | | +1 | unit | 201 | hbase-procedure in the patch passed. | | -1 | unit | 15607 | hbase-server in the patch failed. | | +1 | unit | 1548 | hbase-mapreduce in the patch passed. | | +1 | unit | 78 | hbase-it in the patch passed. | | +1 | unit | 329 | hbase-rest in the patch passed. | | +1 | asflicense | 254 | The patch does not generate ASF License warnings. | | | | 21661 | | | Reason | Tests | |---:|:--| | Failed junit tests | hadoop.hbase.client.TestAsyncTableRegionReplicasGet | | | hadoop.hbase.TestIOFencing | | | hadoop.hbase.master.procedure.TestProcedureAdmin | | | hadoop.hbase.client.TestAsyncTableGetMultiThreaded | | | hadoop.hbase.master.balancer.TestStochasticLoadBalancerRegionReplicaLargeCluster | | | hadoop.hbase.master.balancer.TestStochasticLoadBalancerRegionReplicaSameHosts | | | hadoop.hbase.coprocessor.TestMetaTableMetrics | | | hadoop.hbase.client.TestAsyncTableRegionReplicasScan | | | hadoop.hbase.master.procedure.TestProcedurePriority | | | hadoop.hbase.master.balancer.TestStochasticLoadBalancerRegionReplicaHighReplication | | | hadoop.hbase.replication.regionserver.TestWALEntryStream | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-179/2/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/179 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 5500ca2e14f9 4.4.0-145-generic #171-Ubuntu SMP Tue Mar 26 12:43:40 UTC 2019 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | branch-2.1 / 16cc2a3dfd | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | unit | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-179/2/artifact/out/patch-unit-hbase-server.txt | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-179/2/testReport/ | | Max. process+thread count | 4346 (vs. ulimit of 1) | | modules | C: hbase-common hbase-client
[jira] [Commented] (HBASE-22264) Rest Server (master branch) on jdk 11 throws NoClassDefFoundError : javax/annotation/Priority
[
https://issues.apache.org/jira/browse/HBASE-22264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823598#comment-16823598
]
Sean Busbey commented on HBASE-22264:
-
I'll drop my current locally application and rebase master tonight and take a
look. thanks for pushing on this stuff!
> Rest Server (master branch) on jdk 11 throws NoClassDefFoundError :
> javax/annotation/Priority
> -
>
> Key: HBASE-22264
> URL: https://issues.apache.org/jira/browse/HBASE-22264
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22264.master.001.patch,
> hbase-22264.master.002.patch, hbase-22264.master.003.patch
>
>
> This is in continuation with HBASE-22249. When compiled with jdk 8 and run on
> jdk 11, the master branch throws the following exception during an attempt to
> start the hbase rest server:
> {code:java}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> javax/annotation/Priority
> at
> org.glassfish.jersey.model.internal.ComponentBag.modelFor(ComponentBag.java:483)
> at
> org.glassfish.jersey.model.internal.ComponentBag.access$100(ComponentBag.java:89)
> at
> org.glassfish.jersey.model.internal.ComponentBag$5.call(ComponentBag.java:408)
> at
> org.glassfish.jersey.model.internal.ComponentBag$5.call(ComponentBag.java:398)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
> at
> org.glassfish.jersey.model.internal.ComponentBag.registerModel(ComponentBag.java:398)
> at
> org.glassfish.jersey.model.internal.ComponentBag.register(ComponentBag.java:235)
> at
> org.glassfish.jersey.model.internal.CommonConfig.register(CommonConfig.java:420)
> at
> org.glassfish.jersey.server.ResourceConfig.register(ResourceConfig.java:425)
> at org.apache.hadoop.hbase.rest.RESTServer.run(RESTServer.java:245)
> at org.apache.hadoop.hbase.rest.RESTServer.main(RESTServer.java:421)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] Apache-HBase commented on issue #180: HBASE-22231 Removed unused and '*' import
Apache-HBase commented on issue #180: HBASE-22231 Removed unused and '*' import URL: https://github.com/apache/hbase/pull/180#issuecomment-485600746 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 51 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | +1 | test4tests | 0 | The patch appears to include 81 new or modified test files. | ||| _ branch-2.0 Compile Tests _ | | 0 | mvndep | 8 | Maven dependency ordering for branch | | +1 | mvninstall | 170 | branch-2.0 passed | | +1 | compile | 207 | branch-2.0 passed | | +1 | checkstyle | 215 | branch-2.0 passed | | +1 | shadedjars | 247 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 395 | branch-2.0 passed | | +1 | javadoc | 164 | branch-2.0 passed | ||| _ Patch Compile Tests _ | | 0 | mvndep | 14 | Maven dependency ordering for patch | | +1 | mvninstall | 165 | the patch passed | | +1 | compile | 226 | the patch passed | | +1 | javac | 226 | the patch passed | | +1 | checkstyle | 23 | hbase-common: The patch generated 0 new + 11 unchanged - 3 fixed = 11 total (was 14) | | +1 | checkstyle | 33 | hbase-client: The patch generated 0 new + 208 unchanged - 20 fixed = 208 total (was 228) | | +1 | checkstyle | 14 | hbase-zookeeper: The patch generated 0 new + 0 unchanged - 1 fixed = 0 total (was 1) | | +1 | checkstyle | 11 | hbase-replication: The patch generated 0 new + 9 unchanged - 1 fixed = 9 total (was 10) | | +1 | checkstyle | 15 | hbase-procedure: The patch generated 0 new + 1 unchanged - 7 fixed = 1 total (was 8) | | +1 | checkstyle | 72 | hbase-server: The patch generated 0 new + 497 unchanged - 127 fixed = 497 total (was 624) | | +1 | checkstyle | 18 | hbase-mapreduce: The patch generated 0 new + 97 unchanged - 12 fixed = 97 total (was 109) | | +1 | checkstyle | 24 | hbase-it: The patch generated 0 new + 88 unchanged - 9 fixed = 88 total (was 97) | | +1 | checkstyle | 16 | hbase-rest: The patch generated 0 new + 15 unchanged - 3 fixed = 15 total (was 18) | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 245 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 509 | Patch does not cause any errors with Hadoop 2.6.5 2.7.4 or 3.0.0. | | +1 | findbugs | 456 | the patch passed | | +1 | javadoc | 157 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 154 | hbase-common in the patch passed. | | +1 | unit | 186 | hbase-client in the patch passed. | | +1 | unit | 45 | hbase-zookeeper in the patch passed. | | +1 | unit | 15 | hbase-replication in the patch passed. | | +1 | unit | 205 | hbase-procedure in the patch passed. | | -1 | unit | 12104 | hbase-server in the patch failed. | | +1 | unit | 1239 | hbase-mapreduce in the patch passed. | | +1 | unit | 72 | hbase-it in the patch passed. | | +1 | unit | 396 | hbase-rest in the patch passed. | | +1 | asflicense | 230 | The patch does not generate ASF License warnings. | | | | 18308 | | | Reason | Tests | |---:|:--| | Failed junit tests | hadoop.hbase.client.TestAdmin1 | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-180/2/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/180 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 445276d772d3 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | branch-2.0 / 49a27e13c4 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC3 | | unit | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-180/2/artifact/out/patch-unit-hbase-server.txt | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-180/2/testReport/ | | Max. process+thread count | 5346 (vs. ulimit of 1) | | modules | C: hbase-common hbase-client hbase-zookeeper hbase-replication hbase-procedure hbase-server hbase-mapreduce hbase-it hbase-rest U: . | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-180/2/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated.
[GitHub] [hbase] Apache9 commented on issue #162: HBASE-22262 Removed deprecated methods from Filter class
Apache9 commented on issue #162: HBASE-22262 Removed deprecated methods from Filter class URL: https://github.com/apache/hbase/pull/162#issuecomment-485600656 > For sure deprecated for a whole major version? Deprecate in hbase 2.0.0 release? I think 'a whole major version' just means we can not remove deprecated stuff if it is first deprecated in the same major version? For example, it is OK to remove a class in 3.0.0 if it is deprecated in 2.1.0, but you can not remove it in 2.2.0. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase] Apache-HBase commented on issue #178: HBASE-22231 Removed unused and '*' import
Apache-HBase commented on issue #178: HBASE-22231 Removed unused and '*' import URL: https://github.com/apache/hbase/pull/178#issuecomment-485598630 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 77 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | +1 | test4tests | 0 | The patch appears to include 66 new or modified test files. | ||| _ branch-2.2 Compile Tests _ | | 0 | mvndep | 24 | Maven dependency ordering for branch | | +1 | mvninstall | 288 | branch-2.2 passed | | +1 | compile | 190 | branch-2.2 passed | | +1 | checkstyle | 180 | branch-2.2 passed | | +1 | shadedjars | 242 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 328 | branch-2.2 passed | | +1 | javadoc | 121 | branch-2.2 passed | ||| _ Patch Compile Tests _ | | 0 | mvndep | 13 | Maven dependency ordering for patch | | +1 | mvninstall | 236 | the patch passed | | +1 | compile | 169 | the patch passed | | +1 | javac | 169 | the patch passed | | +1 | checkstyle | 21 | hbase-common: The patch generated 0 new + 11 unchanged - 3 fixed = 11 total (was 14) | | +1 | checkstyle | 33 | hbase-client: The patch generated 0 new + 202 unchanged - 18 fixed = 202 total (was 220) | | +1 | checkstyle | 69 | hbase-server: The patch generated 0 new + 278 unchanged - 102 fixed = 278 total (was 380) | | +1 | checkstyle | 19 | hbase-mapreduce: The patch generated 0 new + 91 unchanged - 12 fixed = 91 total (was 103) | | +1 | checkstyle | 15 | hbase-it: The patch generated 0 new + 88 unchanged - 9 fixed = 88 total (was 97) | | +1 | checkstyle | 13 | hbase-rest: The patch generated 0 new + 15 unchanged - 2 fixed = 15 total (was 17) | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 234 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 493 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 368 | the patch passed | | +1 | javadoc | 122 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 157 | hbase-common in the patch passed. | | +1 | unit | 205 | hbase-client in the patch passed. | | -1 | unit | 13952 | hbase-server in the patch failed. | | +1 | unit | 1600 | hbase-mapreduce in the patch passed. | | +1 | unit | 73 | hbase-it in the patch passed. | | +1 | unit | 484 | hbase-rest in the patch passed. | | +1 | asflicense | 193 | The patch does not generate ASF License warnings. | | | | 20089 | | | Reason | Tests | |---:|:--| | Failed junit tests | hadoop.hbase.replication.multiwal.TestReplicationSyncUpToolWithMultipleWAL | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-178/2/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/178 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 42a5c94afa28 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | branch-2.2 / 048d893708 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | unit | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-178/2/artifact/out/patch-unit-hbase-server.txt | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-178/2/testReport/ | | Max. process+thread count | 5159 (vs. ulimit of 1) | | modules | C: hbase-common hbase-client hbase-server hbase-mapreduce hbase-it hbase-rest U: . | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-178/2/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22287) inifinite retries on failed server in RSProcedureDispatcher
[
https://issues.apache.org/jira/browse/HBASE-22287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823593#comment-16823593
]
Duo Zhang commented on HBASE-22287:
---
Has the region server already been marked as dead at master side? If not, then
I think this is intentional. We can only give up when we make sure that the RS
is dead.
> inifinite retries on failed server in RSProcedureDispatcher
> ---
>
> Key: HBASE-22287
> URL: https://issues.apache.org/jira/browse/HBASE-22287
> Project: HBase
> Issue Type: Bug
>Reporter: Sergey Shelukhin
>Priority: Major
>
> We observed this recently on some cluster, I'm still investigating the root
> cause however seems like the retries should have special handling for this
> exception; and separately probably a cap on number of retries
> {noformat}
> 2019-04-20 04:24:27,093 WARN [RSProcedureDispatcher-pool4-t1285]
> procedure.RSProcedureDispatcher: request to server ,17020,1555742560432
> failed due to java.io.IOException: Call to :17020 failed on local exception:
> org.apache.hadoop.hbase.ipc.FailedServerException: This server is in the
> failed servers list: :17020, try=26603, retrying...
> {noformat}
> The corresponding worker is stuck
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21593) closing flags show be set false in HRegion
[
https://issues.apache.org/jira/browse/HBASE-21593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823592#comment-16823592
]
stack commented on HBASE-21593:
---
I don't get setting closing to 'false' when it seems like we are indeed closing
at this stage (Did you see the comment by [~Jan Hentschel] up on the PR?)
> closing flags show be set false in HRegion
> --
>
> Key: HBASE-21593
> URL: https://issues.apache.org/jira/browse/HBASE-21593
> Project: HBase
> Issue Type: Bug
>Reporter: xiaolerzheng
>Assignee: Xu Cang
>Priority: Minor
> Attachments: HBASE-21593.branch-1.001.patch,
> image-2018-12-13-16-04-51-892.png, image-2018-12-13-16-05-09-246.png,
> image-2018-12-13-16-05-36-404.png
>
>
> in HRegion.java
>
>
> 1429 // block waiting for the lock for closing
> 1430 lock.writeLock().lock();
> 1431 this.closing.set(true);
> 1432 status.setStatus("Disabling writes for close");
>
>
>
>
> 1557 } finally {
> {color:#FF} //should here add {color}
> {color:#FF} this.closing.set(false); {color}
> 1558 lock.writeLock().unlock();
> 1559 }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22267) Implement client push back for async client
[ https://issues.apache.org/jira/browse/HBASE-22267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823591#comment-16823591 ] Duo Zhang commented on HBASE-22267: --- This is an existing feature, just port it to async client, so we can completely remove the sync client code on branch HBASE-21512. Linked HBASE-5162 here, you can find more details there. [~xucang]. Thanks. > Implement client push back for async client > --- > > Key: HBASE-22267 > URL: https://issues.apache.org/jira/browse/HBASE-22267 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] Apache9 commented on issue #183: fix PreemptiveFastFailInterceptor clean repeatedFailuresMap issue
Apache9 commented on issue #183: fix PreemptiveFastFailInterceptor clean repeatedFailuresMap issue URL: https://github.com/apache/hbase/pull/183#issuecomment-485597291 Interesting, do you use Preemptive Fail Fast feature in your production? Do you think the feature introduced in [HBASE-16388](https://issues.apache.org/jira/browse/HBASE-16388) can also solve your problem? Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22264) Rest Server (master branch) on jdk 11 throws NoClassDefFoundError : javax/annotation/Priority
[
https://issues.apache.org/jira/browse/HBASE-22264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823582#comment-16823582
]
Sakthi commented on HBASE-22264:
Yes you are right [~busbey]. Also, I don't think that we need javax.activation
in client tarball so I have updated the patch to accomodate the shell error
reported in the qa run. Could you please take a look?
> Rest Server (master branch) on jdk 11 throws NoClassDefFoundError :
> javax/annotation/Priority
> -
>
> Key: HBASE-22264
> URL: https://issues.apache.org/jira/browse/HBASE-22264
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22264.master.001.patch,
> hbase-22264.master.002.patch, hbase-22264.master.003.patch
>
>
> This is in continuation with HBASE-22249. When compiled with jdk 8 and run on
> jdk 11, the master branch throws the following exception during an attempt to
> start the hbase rest server:
> {code:java}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> javax/annotation/Priority
> at
> org.glassfish.jersey.model.internal.ComponentBag.modelFor(ComponentBag.java:483)
> at
> org.glassfish.jersey.model.internal.ComponentBag.access$100(ComponentBag.java:89)
> at
> org.glassfish.jersey.model.internal.ComponentBag$5.call(ComponentBag.java:408)
> at
> org.glassfish.jersey.model.internal.ComponentBag$5.call(ComponentBag.java:398)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
> at
> org.glassfish.jersey.model.internal.ComponentBag.registerModel(ComponentBag.java:398)
> at
> org.glassfish.jersey.model.internal.ComponentBag.register(ComponentBag.java:235)
> at
> org.glassfish.jersey.model.internal.CommonConfig.register(CommonConfig.java:420)
> at
> org.glassfish.jersey.server.ResourceConfig.register(ResourceConfig.java:425)
> at org.apache.hadoop.hbase.rest.RESTServer.run(RESTServer.java:245)
> at org.apache.hadoop.hbase.rest.RESTServer.main(RESTServer.java:421)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] saintstack commented on issue #183: fix PreemptiveFastFailInterceptor clean repeatedFailuresMap issue
saintstack commented on issue #183: fix PreemptiveFastFailInterceptor clean repeatedFailuresMap issue URL: https://github.com/apache/hbase/pull/183#issuecomment-485595940 Is there an Apache HBase JIRA associated with this PR? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (HBASE-22264) Rest Server (master branch) on jdk 11 throws NoClassDefFoundError : javax/annotation/Priority
[
https://issues.apache.org/jira/browse/HBASE-22264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-22264:
---
Attachment: (was: hbase-22264.master.003.patch)
> Rest Server (master branch) on jdk 11 throws NoClassDefFoundError :
> javax/annotation/Priority
> -
>
> Key: HBASE-22264
> URL: https://issues.apache.org/jira/browse/HBASE-22264
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22264.master.001.patch,
> hbase-22264.master.002.patch, hbase-22264.master.003.patch
>
>
> This is in continuation with HBASE-22249. When compiled with jdk 8 and run on
> jdk 11, the master branch throws the following exception during an attempt to
> start the hbase rest server:
> {code:java}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> javax/annotation/Priority
> at
> org.glassfish.jersey.model.internal.ComponentBag.modelFor(ComponentBag.java:483)
> at
> org.glassfish.jersey.model.internal.ComponentBag.access$100(ComponentBag.java:89)
> at
> org.glassfish.jersey.model.internal.ComponentBag$5.call(ComponentBag.java:408)
> at
> org.glassfish.jersey.model.internal.ComponentBag$5.call(ComponentBag.java:398)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
> at
> org.glassfish.jersey.model.internal.ComponentBag.registerModel(ComponentBag.java:398)
> at
> org.glassfish.jersey.model.internal.ComponentBag.register(ComponentBag.java:235)
> at
> org.glassfish.jersey.model.internal.CommonConfig.register(CommonConfig.java:420)
> at
> org.glassfish.jersey.server.ResourceConfig.register(ResourceConfig.java:425)
> at org.apache.hadoop.hbase.rest.RESTServer.run(RESTServer.java:245)
> at org.apache.hadoop.hbase.rest.RESTServer.main(RESTServer.java:421)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22264) Rest Server (master branch) on jdk 11 throws NoClassDefFoundError : javax/annotation/Priority
[
https://issues.apache.org/jira/browse/HBASE-22264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-22264:
---
Attachment: hbase-22264.master.003.patch
> Rest Server (master branch) on jdk 11 throws NoClassDefFoundError :
> javax/annotation/Priority
> -
>
> Key: HBASE-22264
> URL: https://issues.apache.org/jira/browse/HBASE-22264
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22264.master.001.patch,
> hbase-22264.master.002.patch, hbase-22264.master.003.patch
>
>
> This is in continuation with HBASE-22249. When compiled with jdk 8 and run on
> jdk 11, the master branch throws the following exception during an attempt to
> start the hbase rest server:
> {code:java}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> javax/annotation/Priority
> at
> org.glassfish.jersey.model.internal.ComponentBag.modelFor(ComponentBag.java:483)
> at
> org.glassfish.jersey.model.internal.ComponentBag.access$100(ComponentBag.java:89)
> at
> org.glassfish.jersey.model.internal.ComponentBag$5.call(ComponentBag.java:408)
> at
> org.glassfish.jersey.model.internal.ComponentBag$5.call(ComponentBag.java:398)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
> at
> org.glassfish.jersey.model.internal.ComponentBag.registerModel(ComponentBag.java:398)
> at
> org.glassfish.jersey.model.internal.ComponentBag.register(ComponentBag.java:235)
> at
> org.glassfish.jersey.model.internal.CommonConfig.register(CommonConfig.java:420)
> at
> org.glassfish.jersey.server.ResourceConfig.register(ResourceConfig.java:425)
> at org.apache.hadoop.hbase.rest.RESTServer.run(RESTServer.java:245)
> at org.apache.hadoop.hbase.rest.RESTServer.main(RESTServer.java:421)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22264) Rest Server (master branch) on jdk 11 throws NoClassDefFoundError : javax/annotation/Priority
[
https://issues.apache.org/jira/browse/HBASE-22264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-22264:
---
Attachment: hbase-22264.master.003.patch
> Rest Server (master branch) on jdk 11 throws NoClassDefFoundError :
> javax/annotation/Priority
> -
>
> Key: HBASE-22264
> URL: https://issues.apache.org/jira/browse/HBASE-22264
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22264.master.001.patch,
> hbase-22264.master.002.patch, hbase-22264.master.003.patch
>
>
> This is in continuation with HBASE-22249. When compiled with jdk 8 and run on
> jdk 11, the master branch throws the following exception during an attempt to
> start the hbase rest server:
> {code:java}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> javax/annotation/Priority
> at
> org.glassfish.jersey.model.internal.ComponentBag.modelFor(ComponentBag.java:483)
> at
> org.glassfish.jersey.model.internal.ComponentBag.access$100(ComponentBag.java:89)
> at
> org.glassfish.jersey.model.internal.ComponentBag$5.call(ComponentBag.java:408)
> at
> org.glassfish.jersey.model.internal.ComponentBag$5.call(ComponentBag.java:398)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
> at
> org.glassfish.jersey.model.internal.ComponentBag.registerModel(ComponentBag.java:398)
> at
> org.glassfish.jersey.model.internal.ComponentBag.register(ComponentBag.java:235)
> at
> org.glassfish.jersey.model.internal.CommonConfig.register(CommonConfig.java:420)
> at
> org.glassfish.jersey.server.ResourceConfig.register(ResourceConfig.java:425)
> at org.apache.hadoop.hbase.rest.RESTServer.run(RESTServer.java:245)
> at org.apache.hadoop.hbase.rest.RESTServer.main(RESTServer.java:421)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22282) Should deal with error in the callback of RawAsyncHBaseAdmin.splitRegion methods
[
https://issues.apache.org/jira/browse/HBASE-22282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823574#comment-16823574
]
Hudson commented on HBASE-22282:
Results for branch branch-2.2
[build #202 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/202/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/202//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/202//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/202//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Should deal with error in the callback of RawAsyncHBaseAdmin.splitRegion
> methods
>
>
> Key: HBASE-22282
> URL: https://issues.apache.org/jira/browse/HBASE-22282
> Project: HBase
> Issue Type: Bug
> Components: Admin, asyncclient
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.1.5, 2.2.1
>
>
> Should be typos...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22215) Backport MultiRowRangeFilter does not work with reverse scans
[
https://issues.apache.org/jira/browse/HBASE-22215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823568#comment-16823568
]
HBase QA commented on HBASE-22215:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 20m
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
20s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
13s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
7s{color} | {color:green} branch-1 passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
11s{color} | {color:green} branch-1 passed with JDK v1.7.0_222 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
8s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
18s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
56s{color} | {color:green} branch-1 passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
13s{color} | {color:green} branch-1 passed with JDK v1.7.0_222 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
5s{color} | {color:green} the patch passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
10s{color} | {color:green} the patch passed with JDK v1.7.0_222 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
9s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
2m 5s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
54s{color} | {color:green} the patch passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
12s{color} | {color:green} the patch passed with JDK v1.7.0_222 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
48s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}146m
42s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
43s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}203m 41s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
[jira] [Updated] (HBASE-22291) Fix recovery of recovered.edits files under root dir
[ https://issues.apache.org/jira/browse/HBASE-22291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zach York updated HBASE-22291: -- Status: Patch Available (was: Open) > Fix recovery of recovered.edits files under root dir > > > Key: HBASE-22291 > URL: https://issues.apache.org/jira/browse/HBASE-22291 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.4.9 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Attachments: HBASE-22291.branch-1.001.patch, > HBASE-22291.master.001.patch > > > It looks like a few places are using incorrect FS instances in the > replayRecoveredEditsForPath method that was introduced in HBASE-20734. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22291) Fix recovery of recovered.edits files under root dir
[ https://issues.apache.org/jira/browse/HBASE-22291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zach York updated HBASE-22291: -- Attachment: HBASE-22291.branch-1.001.patch > Fix recovery of recovered.edits files under root dir > > > Key: HBASE-22291 > URL: https://issues.apache.org/jira/browse/HBASE-22291 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.4.9 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Attachments: HBASE-22291.branch-1.001.patch, > HBASE-22291.master.001.patch > > > It looks like a few places are using incorrect FS instances in the > replayRecoveredEditsForPath method that was introduced in HBASE-20734. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22291) Fix recovery of recovered.edits files under root dir
[ https://issues.apache.org/jira/browse/HBASE-22291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zach York updated HBASE-22291: -- Attachment: HBASE-22291.master.001.patch > Fix recovery of recovered.edits files under root dir > > > Key: HBASE-22291 > URL: https://issues.apache.org/jira/browse/HBASE-22291 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.4.9 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Attachments: HBASE-22291.master.001.patch > > > It looks like a few places are using incorrect FS instances in the > replayRecoveredEditsForPath method that was introduced in HBASE-20734. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22291) Fix recovery of recovered.edits files under root dir
Zach York created HBASE-22291: - Summary: Fix recovery of recovered.edits files under root dir Key: HBASE-22291 URL: https://issues.apache.org/jira/browse/HBASE-22291 Project: HBase Issue Type: Improvement Affects Versions: 1.4.9 Reporter: Zach York Assignee: Zach York It looks like a few places are using incorrect FS instances in the replayRecoveredEditsForPath method that was introduced in HBASE-20734. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-16488) Starting namespace and quota services in master startup asynchronously
[
https://issues.apache.org/jira/browse/HBASE-16488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823564#comment-16823564
]
HBase QA commented on HBASE-16488:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 20m
53s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
1s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 12 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
56s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
36s{color} | {color:green} branch-1 passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
42s{color} | {color:green} branch-1 passed with JDK v1.7.0_222 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
31s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
47s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} branch-1 passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green} branch-1 passed with JDK v1.7.0_222 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
36s{color} | {color:green} the patch passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
44s{color} | {color:green} the patch passed with JDK v1.7.0_222 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
42s{color} | {color:red} hbase-server: The patch generated 1 new + 762
unchanged - 3 fixed = 763 total (was 765) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
33s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
3m 12s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} the patch passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} the patch passed with JDK v1.7.0_222 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}156m 57s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
27s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}206m 10s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.TestMasterBalanceThrottling |
| | hadoop.hbase.security.access.TestAccessController3 |
| | hadoop.hbase.coprocessor.TestCoprocessorEndpoint |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/145/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-16488 |
| JIRA Patch URL |
[jira] [Commented] (HBASE-22020) upgrade to yetus 0.9.0
[ https://issues.apache.org/jira/browse/HBASE-22020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823565#comment-16823565 ] stack commented on HBASE-22020: --- Yeah. +1 for branch-2 and workarounds for branch-1 in another JIRA > upgrade to yetus 0.9.0 > -- > > Key: HBASE-22020 > URL: https://issues.apache.org/jira/browse/HBASE-22020 > Project: HBase > Issue Type: Task > Components: build, community >Reporter: stack >Assignee: Sean Busbey >Priority: Major > Attachments: HBASE-22020-branch-1.v1.patch, HBASE-22020.0.patch, > HBASE-22020.1.patch > > > branch-1/jdk7 checkstyle dtd xml parse complaint; "script engine for language > js can not be found" > See parent for some context. Checkstyle references dtds that were hosted on > puppycrawl, then on sourceforge up until ten days ago. Nightlies are failing > for among other reasons, complaint that there is bad xml in the build... > notably, the unresolvable DTDs. > I'd just update the DTDs but there is a need for a js engine some where and > openjdk7 doesn't ship with one (openjdk8 does). That needs addressing and > then we can backport the parent issue... > See > https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-1/710/artifact/output-general/xml.txt > ... which in case its rolled away, is filled with this message: > "script engine for language js can not be found" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22200) WALSplitter.hasRecoveredEdits should use same FS instance from WAL region dir
[
https://issues.apache.org/jira/browse/HBASE-22200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zach York updated HBASE-22200:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
Let's reopen if we can confirm this is an issue in branch-1.
> WALSplitter.hasRecoveredEdits should use same FS instance from WAL region dir
> -
>
> Key: HBASE-22200
> URL: https://issues.apache.org/jira/browse/HBASE-22200
> Project: HBase
> Issue Type: Bug
> Components: wal
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Major
> Labels: S3, WAL
> Fix For: 3.0.0, 2.0.6, 2.1.5, 2.2.1
>
> Attachments: HBASE-22200-branch-2.1-001.patch,
> HBASE-22200-branch-2.1-002.patch, HBASE-22200-branch-2.1-003.patch,
> HBASE-22200-master-001.patch, HBASE-22200-master-002.patch
>
>
> *WALSplitter.hasRecoveredEdits* should use same FS instance from WAL region
> dir when checking for recovered.edits files, instead of taking FS instance as
> additional method parameter. When specifying different file systems for *wal
> dir* and *root dir*, *WALSplitter.hasRecoveredEdits* current implementation
> will crash or give wrong results. As of now, it's being used indirectly by
> *SplitTableRegionProcedure*. When running tests with *WAL dir* on HDFS and
> *root dir* on S3, for example, noticed region split failing with below error:
> {noformat}
> 2019-04-08 13:53:58,064 ERROR
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor: CODE-BUG: Uncaught
> runtime exception: pid=98,
> state=RUNNABLE:SPLIT_TABLE_REGIONS_CHECK_CLOSED_REGIONS, locked=true;
> SplitTableRegionProcedure table=test-tbl,
> parent=4c5db01611e97e3abbe02e781e867212,
> daughterA=28a0a5e4ef7618899f6bd6dfb5335fe7,
> daughterB=05fa26feaf03ebf9e87e099cbd1eabac
> java.lang.IllegalArgumentException: Path
> hdfs://host-1.example.com:8020/wal_dir/default/test-tbl/4c5db01611e97e3abbe02e781e867212/recovered.edits
> scheme must be s3a
> at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:115)
> at
> org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.checkPath(DynamoDBMetadataStore.java:1127)
> at
> org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.get(DynamoDBMetadataStore.java:437)
> at
> org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2110)
> at
> org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2088)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:442)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1668)
> at
> org.apache.hadoop.hbase.wal.WALSplitter.getSplitEditFilesSorted(WALSplitter.java:576)
> at
> org.apache.hadoop.hbase.wal.WALSplitter.hasRecoveredEdits(WALSplitter.java:558)
> at
> org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.hasRecoveredEdits(SplitTableRegionProcedure.java:148)
> at
> org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.executeFromState(SplitTableRegionProcedure.java:255)
> {noformat}
> Since *WALSplitter.hasRecoveredEdits* already resolves the proper WAL dir for
> the region, we can simply re-use FS instance from the path instance for the
> WAL dir region, when searching for recovered.edits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22083) move eclipse specific configs into a profile
[ https://issues.apache.org/jira/browse/HBASE-22083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823560#comment-16823560 ] stack commented on HBASE-22083: --- Nice one. +1 RN? Does it need mention in refguide? > move eclipse specific configs into a profile > > > Key: HBASE-22083 > URL: https://issues.apache.org/jira/browse/HBASE-22083 > Project: HBase > Issue Type: Task > Components: build >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Minor > Labels: eclipse > Attachments: HBASE-22083.0.patch > > > move our eclipse specific configs into profiles so they don't show up a > non-eclipse build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22200) WALSplitter.hasRecoveredEdits should use same FS instance from WAL region dir
[
https://issues.apache.org/jira/browse/HBASE-22200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zach York updated HBASE-22200:
--
Hadoop Flags: Reviewed
Fix Version/s: 2.2.1
2.1.5
2.0.6
3.0.0
Component/s: wal
> WALSplitter.hasRecoveredEdits should use same FS instance from WAL region dir
> -
>
> Key: HBASE-22200
> URL: https://issues.apache.org/jira/browse/HBASE-22200
> Project: HBase
> Issue Type: Bug
> Components: wal
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Major
> Labels: S3, WAL
> Fix For: 3.0.0, 2.0.6, 2.1.5, 2.2.1
>
> Attachments: HBASE-22200-branch-2.1-001.patch,
> HBASE-22200-branch-2.1-002.patch, HBASE-22200-branch-2.1-003.patch,
> HBASE-22200-master-001.patch, HBASE-22200-master-002.patch
>
>
> *WALSplitter.hasRecoveredEdits* should use same FS instance from WAL region
> dir when checking for recovered.edits files, instead of taking FS instance as
> additional method parameter. When specifying different file systems for *wal
> dir* and *root dir*, *WALSplitter.hasRecoveredEdits* current implementation
> will crash or give wrong results. As of now, it's being used indirectly by
> *SplitTableRegionProcedure*. When running tests with *WAL dir* on HDFS and
> *root dir* on S3, for example, noticed region split failing with below error:
> {noformat}
> 2019-04-08 13:53:58,064 ERROR
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor: CODE-BUG: Uncaught
> runtime exception: pid=98,
> state=RUNNABLE:SPLIT_TABLE_REGIONS_CHECK_CLOSED_REGIONS, locked=true;
> SplitTableRegionProcedure table=test-tbl,
> parent=4c5db01611e97e3abbe02e781e867212,
> daughterA=28a0a5e4ef7618899f6bd6dfb5335fe7,
> daughterB=05fa26feaf03ebf9e87e099cbd1eabac
> java.lang.IllegalArgumentException: Path
> hdfs://host-1.example.com:8020/wal_dir/default/test-tbl/4c5db01611e97e3abbe02e781e867212/recovered.edits
> scheme must be s3a
> at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:115)
> at
> org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.checkPath(DynamoDBMetadataStore.java:1127)
> at
> org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.get(DynamoDBMetadataStore.java:437)
> at
> org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2110)
> at
> org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2088)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:442)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1668)
> at
> org.apache.hadoop.hbase.wal.WALSplitter.getSplitEditFilesSorted(WALSplitter.java:576)
> at
> org.apache.hadoop.hbase.wal.WALSplitter.hasRecoveredEdits(WALSplitter.java:558)
> at
> org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.hasRecoveredEdits(SplitTableRegionProcedure.java:148)
> at
> org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.executeFromState(SplitTableRegionProcedure.java:255)
> {noformat}
> Since *WALSplitter.hasRecoveredEdits* already resolves the proper WAL dir for
> the region, we can simply re-use FS instance from the path instance for the
> WAL dir region, when searching for recovered.edits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22200) WALSplitter.hasRecoveredEdits should use same FS instance from WAL region dir
[
https://issues.apache.org/jira/browse/HBASE-22200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823558#comment-16823558
]
Zach York commented on HBASE-22200:
---
Pushed to all 2.x branches.
[~wchevreuil] can you confirm where the issue is in branch-1? I looked for a
bit and it wasn't immediately obvious since this method doesn't exist (which
might be why this case was missed initially when 20734 was ported to master).
> WALSplitter.hasRecoveredEdits should use same FS instance from WAL region dir
> -
>
> Key: HBASE-22200
> URL: https://issues.apache.org/jira/browse/HBASE-22200
> Project: HBase
> Issue Type: Bug
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Major
> Labels: S3, WAL
> Attachments: HBASE-22200-branch-2.1-001.patch,
> HBASE-22200-branch-2.1-002.patch, HBASE-22200-branch-2.1-003.patch,
> HBASE-22200-master-001.patch, HBASE-22200-master-002.patch
>
>
> *WALSplitter.hasRecoveredEdits* should use same FS instance from WAL region
> dir when checking for recovered.edits files, instead of taking FS instance as
> additional method parameter. When specifying different file systems for *wal
> dir* and *root dir*, *WALSplitter.hasRecoveredEdits* current implementation
> will crash or give wrong results. As of now, it's being used indirectly by
> *SplitTableRegionProcedure*. When running tests with *WAL dir* on HDFS and
> *root dir* on S3, for example, noticed region split failing with below error:
> {noformat}
> 2019-04-08 13:53:58,064 ERROR
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor: CODE-BUG: Uncaught
> runtime exception: pid=98,
> state=RUNNABLE:SPLIT_TABLE_REGIONS_CHECK_CLOSED_REGIONS, locked=true;
> SplitTableRegionProcedure table=test-tbl,
> parent=4c5db01611e97e3abbe02e781e867212,
> daughterA=28a0a5e4ef7618899f6bd6dfb5335fe7,
> daughterB=05fa26feaf03ebf9e87e099cbd1eabac
> java.lang.IllegalArgumentException: Path
> hdfs://host-1.example.com:8020/wal_dir/default/test-tbl/4c5db01611e97e3abbe02e781e867212/recovered.edits
> scheme must be s3a
> at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:115)
> at
> org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.checkPath(DynamoDBMetadataStore.java:1127)
> at
> org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.get(DynamoDBMetadataStore.java:437)
> at
> org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2110)
> at
> org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2088)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:442)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1668)
> at
> org.apache.hadoop.hbase.wal.WALSplitter.getSplitEditFilesSorted(WALSplitter.java:576)
> at
> org.apache.hadoop.hbase.wal.WALSplitter.hasRecoveredEdits(WALSplitter.java:558)
> at
> org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.hasRecoveredEdits(SplitTableRegionProcedure.java:148)
> at
> org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.executeFromState(SplitTableRegionProcedure.java:255)
> {noformat}
> Since *WALSplitter.hasRecoveredEdits* already resolves the proper WAL dir for
> the region, we can simply re-use FS instance from the path instance for the
> WAL dir region, when searching for recovered.edits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] Apache-HBase commented on issue #184: HBASE-19303 Removed ReplicationAdmin and all its usages
Apache-HBase commented on issue #184: HBASE-19303 Removed ReplicationAdmin and all its usages URL: https://github.com/apache/hbase/pull/184#issuecomment-485580929 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 28 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | +1 | test4tests | 0 | The patch appears to include 17 new or modified test files. | ||| _ master Compile Tests _ | | 0 | mvndep | 23 | Maven dependency ordering for branch | | +1 | mvninstall | 263 | master passed | | +1 | compile | 106 | master passed | | +1 | checkstyle | 116 | master passed | | +1 | shadedjars | 280 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 272 | master passed | | +1 | javadoc | 66 | master passed | ||| _ Patch Compile Tests _ | | 0 | mvndep | 14 | Maven dependency ordering for patch | | +1 | mvninstall | 248 | the patch passed | | +1 | compile | 101 | the patch passed | | +1 | javac | 101 | the patch passed | | +1 | checkstyle | 29 | hbase-client: The patch generated 0 new + 0 unchanged - 33 fixed = 0 total (was 33) | | +1 | checkstyle | 70 | hbase-server: The patch generated 0 new + 25 unchanged - 3 fixed = 25 total (was 28) | | +1 | checkstyle | 13 | The patch passed checkstyle in hbase-it | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 270 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 538 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 316 | the patch passed | | +1 | javadoc | 66 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 190 | hbase-client in the patch passed. | | -1 | unit | 7762 | hbase-server in the patch failed. | | +1 | unit | 67 | hbase-it in the patch passed. | | +1 | asflicense | 90 | The patch does not generate ASF License warnings. | | | | 11030 | | | Reason | Tests | |---:|:--| | Failed junit tests | hadoop.hbase.replication.TestPerTableCFReplication | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-184/1/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/184 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux bb93f2ddc372 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | master / 01d3d32b16 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | unit | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-184/1/artifact/out/patch-unit-hbase-server.txt | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-184/1/testReport/ | | Max. process+thread count | 4721 (vs. ulimit of 1) | | modules | C: hbase-client hbase-server hbase-it U: . | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-184/1/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (HBASE-22274) Cell size limit check on append should consider cell's previous size.
[
https://issues.apache.org/jira/browse/HBASE-22274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Cang updated HBASE-22274:
Attachment: HBASE-22274-master.002.patch
> Cell size limit check on append should consider cell's previous size.
> -
>
> Key: HBASE-22274
> URL: https://issues.apache.org/jira/browse/HBASE-22274
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0, 1.3.5
>Reporter: Xu Cang
>Assignee: Xu Cang
>Priority: Minor
> Attachments: HBASE-22274-master.001.patch,
> HBASE-22274-master.002.patch, HBASE-22274-master.002.patch
>
>
> Now we have cell size limit check based on this parameter
> *hbase.server.keyvalue.maxsize*
> One case was missing: appending to a cell only take append op's cell size
> into account against this limit check. we should check against the potential
> final cell size after the append.'
> It's easy to reproduce this :
>
> Apply this diff
>
> {code:java}
> diff --git
> a/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
>
> b/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
> index 5a285ef6ba..8633177ebe 100644 ---
> a/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
> +++
> b/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
> @@ -6455,7 +6455,7
> - t.append(new Append(ROW).addColumn(FAMILY, QUALIFIER, new byte[10 *
> 1024]));
> + t.append(new Append(ROW).addColumn(FAMILY, QUALIFIER, new byte[2 * 1024]));
> {code}
>
> Fix is to add this check in #reckonDeltas in HRegion class, where we have
> already got the appended cell's size.
> Will throw DoNotRetryIOException if checks is failed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22206) dist.apache.org must not be used for public downloads
[
https://issues.apache.org/jira/browse/HBASE-22206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823526#comment-16823526
]
Hudson commented on HBASE-22206:
Results for branch master
[build #953 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/953/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> dist.apache.org must not be used for public downloads
> -
>
> Key: HBASE-22206
> URL: https://issues.apache.org/jira/browse/HBASE-22206
> Project: HBase
> Issue Type: Bug
> Components: website
>Reporter: Sebb
>Assignee: Dima Spivak
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-22206.master.001.patch,
> HBASE-22206.master.001.patch
>
>
> The dist.apache.org server is only intended for use by developers in staging
> releases.
> It must not be used on public download pages.
> Please use www.apache.org/dist (for KEYS, hashes and sigs) and the mirror
> system instead.
> The current download page has lots of references to dist.a.o; please replace
> thes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21879) Read HFile's block to ByteBuffer directly instead of to byte for reducing young gc purpose
[
https://issues.apache.org/jira/browse/HBASE-21879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823523#comment-16823523
]
Hudson commented on HBASE-21879:
Results for branch HBASE-21879
[build #72 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/72/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/72//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/72//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/72//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Read HFile's block to ByteBuffer directly instead of to byte for reducing
> young gc purpose
> --
>
> Key: HBASE-21879
> URL: https://issues.apache.org/jira/browse/HBASE-21879
> Project: HBase
> Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21879.v1.patch, HBASE-21879.v1.patch,
> QPS-latencies-before-HBASE-21879.png, gc-data-before-HBASE-21879.png
>
>
> In HFileBlock#readBlockDataInternal, we have the following:
> {code}
> @VisibleForTesting
> protected HFileBlock readBlockDataInternal(FSDataInputStream is, long offset,
> long onDiskSizeWithHeaderL, boolean pread, boolean verifyChecksum,
> boolean updateMetrics)
> throws IOException {
> // .
> // TODO: Make this ByteBuffer-based. Will make it easier to go to HDFS with
> BBPool (offheap).
> byte [] onDiskBlock = new byte[onDiskSizeWithHeader + hdrSize];
> int nextBlockOnDiskSize = readAtOffset(is, onDiskBlock, preReadHeaderSize,
> onDiskSizeWithHeader - preReadHeaderSize, true, offset +
> preReadHeaderSize, pread);
> if (headerBuf != null) {
> // ...
> }
> // ...
> }
> {code}
> In the read path, we still read the block from hfile to on-heap byte[], then
> copy the on-heap byte[] to offheap bucket cache asynchronously, and in my
> 100% get performance test, I also observed some frequent young gc, The
> largest memory footprint in the young gen should be the on-heap block byte[].
> In fact, we can read HFile's block to ByteBuffer directly instead of to
> byte[] for reducing young gc purpose. we did not implement this before,
> because no ByteBuffer reading interface in the older HDFS client, but 2.7+
> has supported this now, so we can fix this now. I think.
> Will provide an patch and some perf-comparison for this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22268) Update shading for javax.activation
[
https://issues.apache.org/jira/browse/HBASE-22268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823527#comment-16823527
]
Hudson commented on HBASE-22268:
Results for branch master
[build #953 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/953/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Update shading for javax.activation
> ---
>
> Key: HBASE-22268
> URL: https://issues.apache.org/jira/browse/HBASE-22268
> Project: HBase
> Issue Type: Bug
> Components: hadoop3, java, shading
>Reporter: Adam Antal
>Assignee: Adam Antal
>Priority: Minor
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-22268.master.001.patch,
> HBASE-22268.master.002.patch
>
>
> The javax.activation dependency is added in Hadoop trunk (3.3.0,
> HADOOP-15775) and HBase does not compile against hadoop trunk successfully.
> It is required for supporting JDK11 in Hadoop.
> HBASE-22087 will concern other dependencies.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22279) Add a getRegionLocator method in Table/AsyncTable interface
[
https://issues.apache.org/jira/browse/HBASE-22279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823525#comment-16823525
]
Hudson commented on HBASE-22279:
Results for branch master
[build #953 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/953/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add a getRegionLocator method in Table/AsyncTable interface
> ---
>
> Key: HBASE-22279
> URL: https://issues.apache.org/jira/browse/HBASE-22279
> Project: HBase
> Issue Type: Improvement
> Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
>
> As it is used in shell, for now we just call the getRegionLocator method in
> HTable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19222) update jruby to 9.1.17.0
[
https://issues.apache.org/jira/browse/HBASE-19222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823528#comment-16823528
]
Hudson commented on HBASE-19222:
Results for branch master
[build #953 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/953/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/953//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> update jruby to 9.1.17.0
>
>
> Key: HBASE-19222
> URL: https://issues.apache.org/jira/browse/HBASE-19222
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Reporter: Sean Busbey
>Assignee: Peter Somogyi
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-19222.master.001.patch
>
>
> JRuby's 9.1.14.0 release is described as "things generally work in jdk9"
> https://twitter.com/headius/status/928405094407827457
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823529#comment-16823529
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #189 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/189/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/189//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/189//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/189//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
> Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need
> to set a delay and use a thread pool any more, which could reduce the
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely,
> and start to rewrite the old sync client based on the async client, which
> could reduce the code base a lot for our client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22268) Update shading for javax.activation
[
https://issues.apache.org/jira/browse/HBASE-22268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823519#comment-16823519
]
Hudson commented on HBASE-22268:
Results for branch branch-2
[build #1837 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Update shading for javax.activation
> ---
>
> Key: HBASE-22268
> URL: https://issues.apache.org/jira/browse/HBASE-22268
> Project: HBase
> Issue Type: Bug
> Components: hadoop3, java, shading
>Reporter: Adam Antal
>Assignee: Adam Antal
>Priority: Minor
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-22268.master.001.patch,
> HBASE-22268.master.002.patch
>
>
> The javax.activation dependency is added in Hadoop trunk (3.3.0,
> HADOOP-15775) and HBase does not compile against hadoop trunk successfully.
> It is required for supporting JDK11 in Hadoop.
> HBASE-22087 will concern other dependencies.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22279) Add a getRegionLocator method in Table/AsyncTable interface
[
https://issues.apache.org/jira/browse/HBASE-22279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823518#comment-16823518
]
Hudson commented on HBASE-22279:
Results for branch branch-2
[build #1837 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add a getRegionLocator method in Table/AsyncTable interface
> ---
>
> Key: HBASE-22279
> URL: https://issues.apache.org/jira/browse/HBASE-22279
> Project: HBase
> Issue Type: Improvement
> Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
>
> As it is used in shell, for now we just call the getRegionLocator method in
> HTable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19222) update jruby to 9.1.17.0
[
https://issues.apache.org/jira/browse/HBASE-19222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823520#comment-16823520
]
Hudson commented on HBASE-19222:
Results for branch branch-2
[build #1837 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> update jruby to 9.1.17.0
>
>
> Key: HBASE-19222
> URL: https://issues.apache.org/jira/browse/HBASE-19222
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Reporter: Sean Busbey
>Assignee: Peter Somogyi
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-19222.master.001.patch
>
>
> JRuby's 9.1.14.0 release is described as "things generally work in jdk9"
> https://twitter.com/headius/status/928405094407827457
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22282) Should deal with error in the callback of RawAsyncHBaseAdmin.splitRegion methods
[
https://issues.apache.org/jira/browse/HBASE-22282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823517#comment-16823517
]
Hudson commented on HBASE-22282:
Results for branch branch-2
[build #1837 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1837//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Should deal with error in the callback of RawAsyncHBaseAdmin.splitRegion
> methods
>
>
> Key: HBASE-22282
> URL: https://issues.apache.org/jira/browse/HBASE-22282
> Project: HBase
> Issue Type: Bug
> Components: Admin, asyncclient
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.1.5, 2.2.1
>
>
> Should be typos...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] Apache-HBase commented on issue #177: HBASE-22231 Removed unused and '*' import
Apache-HBase commented on issue #177: HBASE-22231 Removed unused and '*' import URL: https://github.com/apache/hbase/pull/177#issuecomment-485571992 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 26 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | +1 | test4tests | 0 | The patch appears to include 64 new or modified test files. | ||| _ branch-2 Compile Tests _ | | 0 | mvndep | 20 | Maven dependency ordering for branch | | +1 | mvninstall | 222 | branch-2 passed | | +1 | compile | 174 | branch-2 passed | | +1 | checkstyle | 169 | branch-2 passed | | +1 | shadedjars | 237 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 335 | branch-2 passed | | +1 | javadoc | 116 | branch-2 passed | ||| _ Patch Compile Tests _ | | 0 | mvndep | 13 | Maven dependency ordering for patch | | +1 | mvninstall | 221 | the patch passed | | +1 | compile | 164 | the patch passed | | +1 | javac | 164 | the patch passed | | +1 | checkstyle | 21 | hbase-common: The patch generated 0 new + 11 unchanged - 3 fixed = 11 total (was 14) | | +1 | checkstyle | 31 | hbase-client: The patch generated 0 new + 202 unchanged - 18 fixed = 202 total (was 220) | | +1 | checkstyle | 65 | hbase-server: The patch generated 0 new + 277 unchanged - 100 fixed = 277 total (was 377) | | +1 | checkstyle | 18 | hbase-mapreduce: The patch generated 0 new + 91 unchanged - 11 fixed = 91 total (was 102) | | +1 | checkstyle | 14 | hbase-it: The patch generated 0 new + 88 unchanged - 9 fixed = 88 total (was 97) | | +1 | checkstyle | 14 | hbase-rest: The patch generated 0 new + 15 unchanged - 2 fixed = 15 total (was 17) | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 229 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 465 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 378 | the patch passed | | +1 | javadoc | 114 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 156 | hbase-common in the patch passed. | | +1 | unit | 193 | hbase-client in the patch passed. | | +1 | unit | 7974 | hbase-server in the patch passed. | | +1 | unit | 977 | hbase-mapreduce in the patch passed. | | +1 | unit | 70 | hbase-it in the patch passed. | | +1 | unit | 252 | hbase-rest in the patch passed. | | +1 | asflicense | 203 | The patch does not generate ASF License warnings. | | | | 13021 | | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-177/2/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/177 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 0833eda827a7 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | branch-2 / c9b283ec2e | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-177/2/testReport/ | | Max. process+thread count | 5480 (vs. ulimit of 1) | | modules | C: hbase-common hbase-client hbase-server hbase-mapreduce hbase-it hbase-rest U: . | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-177/2/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (HBASE-22289) WAL-based log splitting resubmit threshold results in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HBASE-22289:
-
Attachment: HBASE-22289.01-branch-2.1.patch
> WAL-based log splitting resubmit threshold results in a task being stuck
> forever
>
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 1.5.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22289.01-branch-2.1.patch
>
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22289) WAL-based log splitting resubmit threshold results in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HBASE-22289:
-
Status: Patch Available (was: Open)
> WAL-based log splitting resubmit threshold results in a task being stuck
> forever
>
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 1.5.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22289.01-branch-2.1.patch
>
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22289) WAL-based log splitting resubmit threshold may result in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HBASE-22289:
-
Summary: WAL-based log splitting resubmit threshold may result in a task
being stuck forever (was: WAL-based log splitting resubmit threshold results
in a task being stuck forever)
> WAL-based log splitting resubmit threshold may result in a task being stuck
> forever
> ---
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 1.5.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22289.01-branch-2.1.patch
>
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-22289) WAL-based log splitting resubmit threshold results in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin reassigned HBASE-22289:
Assignee: Sergey Shelukhin
> WAL-based log splitting resubmit threshold results in a task being stuck
> forever
>
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 1.5.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Major
> Fix For: 2.1.5
>
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22289) WAL-based log splitting resubmit threshold results in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HBASE-22289:
-
Affects Version/s: 1.5.0
2.1.0
> WAL-based log splitting resubmit threshold results in a task being stuck
> forever
>
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 1.5.0
>Reporter: Sergey Shelukhin
>Priority: Major
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22289) WAL-based log splitting resubmit threshold results in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HBASE-22289:
-
Fix Version/s: 2.1.5
> WAL-based log splitting resubmit threshold results in a task being stuck
> forever
>
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 1.5.0
>Reporter: Sergey Shelukhin
>Priority: Major
> Fix For: 2.1.5
>
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22289) WAL-based log splitting resubmit threshold results in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823507#comment-16823507
]
Sergey Shelukhin commented on HBASE-22289:
--
Actually nm, ZK error was a red herring (although it could still happen if
other ZK update fails; in this case it was actually a take-ownership that
failed, and it succeeded on retry).
I see that RS logged handler.WALSplitterHandler: task execution preempted for
this task.
That led me to this helpful TODO:
{noformat}
// TODO have to correctly figure out when log splitting has been
// interrupted or has encountered a transient error and when it has
// encountered a bad non-retry-able persistent error.
if (!WALSplitter.splitLogFile(walDir, fs.getFileStatus(new Path(walDir,
name)), fs, conf, p,
sequenceIdChecker, splitLogWorkerCoordination, factory)) {
return Status.PREEMPTED;
}
{noformat}
When task is preempted RS in fact never updates task for the master. I'm not
sure what the logic is behind that, what is master supposed to gain from not
having the updated information.
> WAL-based log splitting resubmit threshold results in a task being stuck
> forever
>
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Reporter: Sergey Shelukhin
>Priority: Major
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19003) Make sure all balancer actions respect decommissioned server
[ https://issues.apache.org/jira/browse/HBASE-19003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-19003: -- Labels: balancer (was: ) > Make sure all balancer actions respect decommissioned server > > > Key: HBASE-19003 > URL: https://issues.apache.org/jira/browse/HBASE-19003 > Project: HBase > Issue Type: Sub-task >Reporter: Jerry He >Assignee: Jerry He >Priority: Major > Labels: balancer > Fix For: 2.0.0-beta-1, 2.0.0 > > > There have been questions raised in HBASE-10367 and other related JIRAs. We > want to make sure all aspects of the balancer respect the draining flag. We > will have a good look, and fix if any violation is found. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19003) Make sure all balancer actions respect decommissioned server
[ https://issues.apache.org/jira/browse/HBASE-19003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-19003: -- Component/s: Balancer > Make sure all balancer actions respect decommissioned server > > > Key: HBASE-19003 > URL: https://issues.apache.org/jira/browse/HBASE-19003 > Project: HBase > Issue Type: Sub-task > Components: Balancer >Reporter: Jerry He >Assignee: Jerry He >Priority: Major > Labels: balancer > Fix For: 2.0.0-beta-1, 2.0.0 > > > There have been questions raised in HBASE-10367 and other related JIRAs. We > want to make sure all aspects of the balancer respect the draining flag. We > will have a good look, and fix if any violation is found. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22289) WAL-based log splitting resubmit threshold results in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823503#comment-16823503
]
Sergey Shelukhin commented on HBASE-22289:
--
So the root cause is that for this task in particular, RS'es ZK operation to
report error failed permanently against ZK, this RS was having a bad time but
then recovered.
Basically ZK task update from RS is a critical message and if it is lost but RS
doesn't die, master will forever think the task is in progress.
And if the resubmit threshold happens to be hit, it will never resubmit the "in
progress" task. Hence it will be stuck until either worker RS or master die.
[~tianjingyun] Not sure if procedures-based implementation in HBASE-21588 is
affected by a similar issue if the message from RS to master is lost. Worth
checking, because OpenRegion proc has special handling for this, where RS
reports to master and kills itself if the report fails (otherwise if the
message is lost that too will be stuck forever)
That might be what needs to be done for ZK implementation too pre-2.2. The
proper fix would be to get rid of imperative updates and report/handle current
state, but it's too much of a change for older branches given that ZK impl is
abandoned.
> WAL-based log splitting resubmit threshold results in a task being stuck
> forever
>
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Reporter: Sergey Shelukhin
>Priority: Major
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-17499) Bound the total heap memory used for the rolling average of RegionLoads
[ https://issues.apache.org/jira/browse/HBASE-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-17499: -- Component/s: Balancer > Bound the total heap memory used for the rolling average of RegionLoads > --- > > Key: HBASE-17499 > URL: https://issues.apache.org/jira/browse/HBASE-17499 > Project: HBase > Issue Type: Improvement > Components: Balancer >Reporter: Ted Yu >Priority: Major > Labels: balancer > > Currently "hbase.master.balancer.stochastic.numRegionLoadsToRemember" > controls the number of RegionLoads which are kept by StochasticLoadBalancer > for each region. > The parameter doesn't take into account the number of regions in the cluster. > Meaning, the amount of heap consumed by RegionLoads would be out of norm for > cluster with large number of regions. > This issue is to see if we should bound the total heap memory used for the > rolling average of RegionLoads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19440) Not able to enable balancer with RSGroups once disabled
[ https://issues.apache.org/jira/browse/HBASE-19440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-19440: -- Component/s: Balancer > Not able to enable balancer with RSGroups once disabled > --- > > Key: HBASE-19440 > URL: https://issues.apache.org/jira/browse/HBASE-19440 > Project: HBase > Issue Type: Bug > Components: Balancer >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan >Priority: Major > Labels: balancer > Fix For: 1.4.0 > > Attachments: HBASE-19440.branch-1.001.patch > > > Once the balancer is disabled, trying to switch it back on doesn't work since > the prebalanceswitch coprocessor hook is incorrectly always returning false. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19440) Not able to enable balancer with RSGroups once disabled
[ https://issues.apache.org/jira/browse/HBASE-19440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-19440: -- Labels: balancer (was: ) > Not able to enable balancer with RSGroups once disabled > --- > > Key: HBASE-19440 > URL: https://issues.apache.org/jira/browse/HBASE-19440 > Project: HBase > Issue Type: Bug >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan >Priority: Major > Labels: balancer > Fix For: 1.4.0 > > Attachments: HBASE-19440.branch-1.001.patch > > > Once the balancer is disabled, trying to switch it back on doesn't work since > the prebalanceswitch coprocessor hook is incorrectly always returning false. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-18765) The value of balancerRan is true even though no plans are executed
[
https://issues.apache.org/jira/browse/HBASE-18765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Biju Nair updated HBASE-18765:
--
Component/s: Balancer
> The value of balancerRan is true even though no plans are executed
> --
>
> Key: HBASE-18765
> URL: https://issues.apache.org/jira/browse/HBASE-18765
> Project: HBase
> Issue Type: Bug
> Components: Balancer, rsgroup
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Minor
> Labels: balancer
> Fix For: 2.0.0-alpha-3, 2.0.0
>
> Attachments: HBASE-18765.v0.patch
>
>
> {code}
> //We balance per group instead of per table
> List plans = new ArrayList<>();
> for(Map.Entry>> tableMap:
> getRSGroupAssignmentsByTable(groupName).entrySet()) {
> LOG.info("Creating partial plan for table " + tableMap.getKey() + ": "
> + tableMap.getValue());
> List partialPlans =
> balancer.balanceCluster(tableMap.getValue());
> LOG.info("Partial plan for table " + tableMap.getKey() + ": " +
> partialPlans);
> if (partialPlans != null) {
> plans.addAll(partialPlans);
> }
> }
> long startTime = System.currentTimeMillis();
> balancerRan = plans != null;
> {code}
> The *plans* is never null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-18765) The value of balancerRan is true even though no plans are executed
[
https://issues.apache.org/jira/browse/HBASE-18765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Biju Nair updated HBASE-18765:
--
Labels: balancer (was: )
> The value of balancerRan is true even though no plans are executed
> --
>
> Key: HBASE-18765
> URL: https://issues.apache.org/jira/browse/HBASE-18765
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Minor
> Labels: balancer
> Fix For: 2.0.0-alpha-3, 2.0.0
>
> Attachments: HBASE-18765.v0.patch
>
>
> {code}
> //We balance per group instead of per table
> List plans = new ArrayList<>();
> for(Map.Entry>> tableMap:
> getRSGroupAssignmentsByTable(groupName).entrySet()) {
> LOG.info("Creating partial plan for table " + tableMap.getKey() + ": "
> + tableMap.getValue());
> List partialPlans =
> balancer.balanceCluster(tableMap.getValue());
> LOG.info("Partial plan for table " + tableMap.getKey() + ": " +
> partialPlans);
> if (partialPlans != null) {
> plans.addAll(partialPlans);
> }
> }
> long startTime = System.currentTimeMillis();
> balancerRan = plans != null;
> {code}
> The *plans* is never null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19021) Restore a few important missing logics for balancer in 2.0
[
https://issues.apache.org/jira/browse/HBASE-19021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Biju Nair updated HBASE-19021:
--
Labels: balancer (was: )
> Restore a few important missing logics for balancer in 2.0
> --
>
> Key: HBASE-19021
> URL: https://issues.apache.org/jira/browse/HBASE-19021
> Project: HBase
> Issue Type: Bug
> Components: Balancer
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Critical
> Labels: balancer
> Fix For: 2.0.0-alpha-4, 2.0.0
>
> Attachments: HBASE-19021-master-v2.patch, HBASE-19021-master.patch,
> HBASE-19021-master.patch
>
>
> After looking at the code, and some testing, I see the following things are
> missing for balancer to work properly after AMv2.
> # hbase.master.loadbalance.bytable is not respected. It is always 'bytable'.
> Previous default is cluster wide, not by table.
> # Servers with no assignments is not added for balance consideration.
> # Crashed server is not removed from the in-memory server map in
> RegionStates, which affects balance.
> # Draining marker is not respected when balance.
> Also try to re-enable {{TestRegionRebalancing}}, which has a
> {{testRebalanceOnRegionServerNumberChange}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] Apache-HBase commented on issue #144: HBASE-22232 Removed deprecated methods in CompareFilter
Apache-HBase commented on issue #144: HBASE-22232 Removed deprecated methods in CompareFilter URL: https://github.com/apache/hbase/pull/144#issuecomment-485563780 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 24 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | +1 | test4tests | 0 | The patch appears to include 10 new or modified test files. | ||| _ master Compile Tests _ | | 0 | mvndep | 23 | Maven dependency ordering for branch | | +1 | mvninstall | 240 | master passed | | +1 | compile | 133 | master passed | | +1 | checkstyle | 156 | master passed | | +1 | shadedjars | 265 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 389 | master passed | | +1 | javadoc | 101 | master passed | ||| _ Patch Compile Tests _ | | 0 | mvndep | 13 | Maven dependency ordering for patch | | +1 | mvninstall | 231 | the patch passed | | +1 | compile | 134 | the patch passed | | +1 | javac | 134 | the patch passed | | +1 | checkstyle | 33 | hbase-client: The patch generated 0 new + 186 unchanged - 52 fixed = 186 total (was 238) | | +1 | checkstyle | 66 | hbase-server: The patch generated 0 new + 90 unchanged - 9 fixed = 90 total (was 99) | | +1 | checkstyle | 28 | The patch passed checkstyle in hbase-thrift | | +1 | checkstyle | 16 | hbase-rest: The patch generated 0 new + 242 unchanged - 3 fixed = 242 total (was 245) | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 258 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 501 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 429 | the patch passed | | +1 | javadoc | 101 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 200 | hbase-client in the patch passed. | | +1 | unit | 8249 | hbase-server in the patch passed. | | +1 | unit | 223 | hbase-thrift in the patch passed. | | +1 | unit | 306 | hbase-rest in the patch passed. | | +1 | asflicense | 96 | The patch does not generate ASF License warnings. | | | | 12339 | | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-144/4/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/144 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 786bab52670f 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | master / 2067b23c8c | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-144/4/testReport/ | | Max. process+thread count | 5288 (vs. ulimit of 1) | | modules | C: hbase-client hbase-server hbase-thrift hbase-rest U: . | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-144/4/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (HBASE-19021) Restore a few important missing logics for balancer in 2.0
[
https://issues.apache.org/jira/browse/HBASE-19021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Biju Nair updated HBASE-19021:
--
Component/s: Balancer
> Restore a few important missing logics for balancer in 2.0
> --
>
> Key: HBASE-19021
> URL: https://issues.apache.org/jira/browse/HBASE-19021
> Project: HBase
> Issue Type: Bug
> Components: Balancer
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Critical
> Fix For: 2.0.0-alpha-4, 2.0.0
>
> Attachments: HBASE-19021-master-v2.patch, HBASE-19021-master.patch,
> HBASE-19021-master.patch
>
>
> After looking at the code, and some testing, I see the following things are
> missing for balancer to work properly after AMv2.
> # hbase.master.loadbalance.bytable is not respected. It is always 'bytable'.
> Previous default is cluster wide, not by table.
> # Servers with no assignments is not added for balance consideration.
> # Crashed server is not removed from the in-memory server map in
> RegionStates, which affects balance.
> # Draining marker is not respected when balance.
> Also try to re-enable {{TestRegionRebalancing}}, which has a
> {{testRebalanceOnRegionServerNumberChange}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-17658) Fix bookkeeping error with max regions for a table
[ https://issues.apache.org/jira/browse/HBASE-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-17658: -- Labels: balancer (was: ) > Fix bookkeeping error with max regions for a table > -- > > Key: HBASE-17658 > URL: https://issues.apache.org/jira/browse/HBASE-17658 > Project: HBase > Issue Type: Bug > Components: Balancer >Reporter: Tim Brown >Assignee: Tim Brown >Priority: Major > Labels: balancer > Fix For: 1.4.0, 1.3.2, 2.0.0, 1.2.7 > > Attachments: JIRA-17658.master.001.patch > > > Currently when numMaxRegionsPerTable of a given table increases above the > current maximum, the value is not properly updated. This means that the cost > for Table Skew cannot get worse for a given region move during the balancer > process leading to an imbalanced cluster with respect to Table Skew. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-18480) The cost of BaseLoadBalancer.cluster is changed even if the rollback is done
[ https://issues.apache.org/jira/browse/HBASE-18480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-18480: -- Labels: balancer (was: ) > The cost of BaseLoadBalancer.cluster is changed even if the rollback is done > > > Key: HBASE-18480 > URL: https://issues.apache.org/jira/browse/HBASE-18480 > Project: HBase > Issue Type: Bug > Components: Balancer >Affects Versions: 3.0.0, 1.3.0, 1.2.6, 2.0.0-alpha-1 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Major > Labels: balancer > Fix For: 1.4.0, 1.3.2, 2.0.0-alpha-2, 2.0.0, 1.2.7 > > Attachments: HBASE-18480.branch-1.2.v0.patch, > HBASE-18480.branch-1.3.v0.patch, HBASE-18480.branch-1.v0.patch, > HBASE-18480.branch-1.v1.patch, HBASE-18480.v0.patch, HBASE-18480.v1.patch, > HBASE-18480.v1.patch > > > If the cost of cluster isn't restored after the undo action, > StochasticLoadBalancer will be hard to generate the "good" action to balance > the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-19322) System tables hbase:quota|hbase:acl will be in offline state when cluster startup first time with rsgroup feature
[
https://issues.apache.org/jira/browse/HBASE-19322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-19322.
---
Resolution: Implemented
Resolving. Implemented by HBASE-20566. Thanks [~gsbiju]
> System tables hbase:quota|hbase:acl will be in offline state when cluster
> startup first time with rsgroup feature
> -
>
> Key: HBASE-19322
> URL: https://issues.apache.org/jira/browse/HBASE-19322
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Affects Versions: 2.0.0-alpha-4
>Reporter: xinxin fan
>Priority: Major
>
> When cluster start up first time with rsgroup feature, system tables
> hbase:quota and hbase:acl will be in OFFLINE state:
> {code:java}
> hbase:quota,,1511254877213.0627adae8630c21f4456984713cdffc8. state=OFFLINE,
> ts=Tue Nov 21 17:03:37 CST 2017 (0s ago), server=localhost,1,1
> {code}
> It seems that the balancer doesn't know which server to assign the
> regions,since that rsgroup information of the two system tables found to be
> null.
> I read the code and found a issue in rsgroup startup procedure : the rsgroup
> starts up before the creating of the two system tables(hbase:quota,
> hbase:acl), so rsgroupStartupWorker only adds hbase:meta and hbase:namespace
> into default group by following function:
> {code:java}
> specialTables =
> masterServices.listTableNamesByNamespace(NamespaceDescriptor.SYSTEM_NAMESPACE_NAME_STR)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20214) Review of RegionLocationFinder Class
[
https://issues.apache.org/jira/browse/HBASE-20214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823495#comment-16823495
]
HBase QA commented on HBASE-20214:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 7s{color}
| {color:red} HBASE-20214 does not apply to master. Rebase required? Wrong
Branch? See
https://yetus.apache.org/documentation/in-progress/precommit-patchnames for
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-20214 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12919468/HBASE-20214.3.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/147/console |
| Powered by | Apache Yetus 0.9.0 http://yetus.apache.org |
This message was automatically generated.
> Review of RegionLocationFinder Class
>
>
> Key: HBASE-20214
> URL: https://issues.apache.org/jira/browse/HBASE-20214
> Project: HBase
> Issue Type: Improvement
> Components: Balancer, master
>Affects Versions: 2.0.0
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Labels: balancer
> Attachments: HBASE-20214.1.patch, HBASE-20214.2.patch,
> HBASE-20214.3.patch
>
>
> # Use SLF4J parameter logging
> # Remove superfluous code
> # Replace code with re-usable libraries where possible
> # Use different data structure
> # Small perf improvements
> # Fix some checkstyle
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20214) Review of RegionLocationFinder Class
[ https://issues.apache.org/jira/browse/HBASE-20214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20214: -- Labels: balancer (was: ) > Review of RegionLocationFinder Class > > > Key: HBASE-20214 > URL: https://issues.apache.org/jira/browse/HBASE-20214 > Project: HBase > Issue Type: Improvement > Components: Balancer, master >Affects Versions: 2.0.0 >Reporter: David Mollitor >Assignee: David Mollitor >Priority: Minor > Labels: balancer > Attachments: HBASE-20214.1.patch, HBASE-20214.2.patch, > HBASE-20214.3.patch > > > # Use SLF4J parameter logging > # Remove superfluous code > # Replace code with re-usable libraries where possible > # Use different data structure > # Small perf improvements > # Fix some checkstyle -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20545) Improve performance of BaseLoadBalancer.retainAssignment
[ https://issues.apache.org/jira/browse/HBASE-20545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20545: -- Labels: balancer (was: ) > Improve performance of BaseLoadBalancer.retainAssignment > > > Key: HBASE-20545 > URL: https://issues.apache.org/jira/browse/HBASE-20545 > Project: HBase > Issue Type: Improvement > Components: Balancer >Affects Versions: 1.4.4, 2.0.0 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Labels: balancer > Fix For: 3.0.0, 2.1.0, 1.3.3, 1.4.5 > > Attachments: HBASE-20545.branch-1.4.001.patch, > HBASE-20545.branch-1.4.002.patch, HBASE-20545.branch-2.001.patch > > > I was measuring perf at scale with a 1m region table and noticed some > improvements can be made to BaseLoadBalancer.retainAssignment(). > retainAssignment() spends a few mins to enable a 1m regions table and also > generates a lot of objects unnecessarily. This jira is to make the most > common case go faster with very minimal changes. A slightly modified version > of this patch takes about 5 seconds for a 1m region table ignoring the time > spent in createCluster(). I think locality can be refreshed during master > startup in different ways without taking time in retainAssignment, but will > follow up on that in subsequent jiras. Leaving it untouched here, but wanted > to call out the time taken without that method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20546) Improve perf of RegionLocationFinder.mapHostNameToServerName
[ https://issues.apache.org/jira/browse/HBASE-20546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20546: -- Labels: banalcer (was: ) > Improve perf of RegionLocationFinder.mapHostNameToServerName > > > Key: HBASE-20546 > URL: https://issues.apache.org/jira/browse/HBASE-20546 > Project: HBase > Issue Type: Improvement > Components: Balancer >Affects Versions: 1.4.4, 2.0.0 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Labels: banalcer > Attachments: HBASE-20546.branch-1.4.001.patch > > > RegionLocationFinder.getTopBlockLocations() is called multiple times during > balancer. While profiling on a large table balance, mapHostNameToServerName() > seem to take a lot of time. One of the maps is repeatedly created for each > iteration, while we can just initialize it once. > Goes into both branch-1 and branch-2, although patches differ slightly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22289) WAL-based log splitting resubmit threshold results in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823487#comment-16823487
]
Sergey Shelukhin commented on HBASE-22289:
--
I see that for other tasks that reached threshold, eventually an error is
detected:
2019-04-21 02:36:52,951 INFO [main-EventThread]
coordination.SplitLogManagerCoordination: Skipping resubmissions of task
.1555832335124 because threshold 3 reached
2019-04-21 02:36:52,951 WARN [main-EventThread]
coordination.SplitLogManagerCoordination: Error splitting .1555832335124
However, no error is logged for the above task. It stays in the tasks map, but
after the threshold flag is set, it's never picked up by the timer again.
> WAL-based log splitting resubmit threshold results in a task being stuck
> forever
>
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Reporter: Sergey Shelukhin
>Priority: Major
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20857) JMX - add Balancer status = enabled / disabled
[ https://issues.apache.org/jira/browse/HBASE-20857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20857: -- Labels: balance (was: ) > JMX - add Balancer status = enabled / disabled > -- > > Key: HBASE-20857 > URL: https://issues.apache.org/jira/browse/HBASE-20857 > Project: HBase > Issue Type: Improvement > Components: API, master, metrics, REST, tooling, Usability >Reporter: Hari Sekhon >Assignee: Kiran Kumar Maturi >Priority: Major > Labels: balance > Fix For: 3.0.0, 2.2.0, 1.4.8, 2.1.1 > > Attachments: HBASE-20857.branch-1.4.001.patch, > HBASE-20857.branch-1.4.002.patch > > > Add HBase Balancer enabled/disabled status to JMX API on HMaster. > Right now the HMaster will give a warning near the top of HMaster UI if > balancer is disabled, but scraping this is for monitoring integration is not > nice, it should be available in JMX API as there is already a > Master,sub=Balancer bean with metrics for the balancer ops etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20701) too much logging when balancer runs from BaseLoadBalancer
[
https://issues.apache.org/jira/browse/HBASE-20701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Biju Nair updated HBASE-20701:
--
Labels: balancer (was: )
> too much logging when balancer runs from BaseLoadBalancer
> -
>
> Key: HBASE-20701
> URL: https://issues.apache.org/jira/browse/HBASE-20701
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Reporter: Mihir Monani
>Assignee: Mihir Monani
>Priority: Trivial
> Labels: balancer
> Fix For: 1.3.3, 1.4.6
>
> Attachments: HBASE-20701-branch-1.3.patch,
> HBASE-20701-branch-1.3.patch, HBASE-20701-branch-1.3.patch,
> HBASE-20701-branch-1.4.patch, HBASE-20701-branch-1.4.patch,
> HBASE-20701.branch-1.001.patch
>
>
> When balancer runs, it tries to find least loaded server with better locality
> for current region. During this, we make debug level logging for each of
> those regions. It creates too much amount of logging at debug level , we
> should move this to trace level logging.
> {code:java}
> int getLeastLoadedTopServerForRegion (int region, int currentServer) {
> ...
> if (leastLoadedServerIndex != -1) {
> LOG.debug("Pick the least loaded server " +
> servers[leastLoadedServerIndex].getHostname()
> + " with better locality for region " + regions[region]);
> }
> ...
> }{code}
> This was fixed in branch-2.0 as part of -HBASE-14614-
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20914) Trim Master memory usage
[ https://issues.apache.org/jira/browse/HBASE-20914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20914: -- Labels: balancer (was: ) > Trim Master memory usage > > > Key: HBASE-20914 > URL: https://issues.apache.org/jira/browse/HBASE-20914 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: stack >Assignee: stack >Priority: Major > Labels: balancer > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.2 > > Attachments: HBASE-20914.branch-2.0.001.patch, Screen Shot 2018-07-19 > at 1.20.23 PM.png, Screen Shot 2018-07-19 at 1.20.23 PM.png, Screen Shot > 2018-07-19 at 1.38.56 PM.png, Screen Shot 2018-07-19 at 1.38.56 PM.png, > Screen Shot 2018-07-19 at 2.22.42 PM.png, Screen Shot 2018-07-19 at 2.22.42 > PM.png, Screen Shot 2018-07-19 at 2.43.42 PM.png, Screen Shot 2018-07-19 at > 2.43.42 PM.png > > > While working on the parent issue, looking at a heap from a Master tha was > running ~650 servers and > 300k regions, I tripped over some silly items in > the heap: > 1. Balancer has a regions x server matrix which takes up 18% of the Master > heap according to jxray and 40% according to eclipse. Looks like the matrix > should be regions x racks which would be much smaller (Issue came in with > HBASE-18164 Fast locality computation in balancer -Added new > LocalityCostFunction and LocalityCandidateGenerator ..). See !Screen Shot > 2018-07-19 at 1.20.23 PM.png! !Screen Shot 2018-07-19 at 1.38.56 PM.png! > 2. Duplicate Strings make up ~5% of the Master heap. Of these, ServerName > seems to be the font. Interesting is report that there 54k instances of > ServerName in this heap though there are only 650 Servers. See !Screen Shot > 2018-07-19 at 2.22.42 PM.png! > 3. ArrayDequeue initializes its internal elements array with 16 elements. We > use this in a few places. In Procedures, of which there are many in this > heap, we near never make use of this array. See !Screen Shot 2018-07-19 at > 2.43.42 PM.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-18581) Remove dead code and some tidy up in BaseLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-18581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-18581: -- Labels: balancer (was: ) > Remove dead code and some tidy up in BaseLoadBalancer > - > > Key: HBASE-18581 > URL: https://issues.apache.org/jira/browse/HBASE-18581 > Project: HBase > Issue Type: Improvement > Components: Balancer >Reporter: Umesh Agashe >Assignee: Umesh Agashe >Priority: Minor > Labels: balancer > Fix For: 2.0.0 > > Attachments: hbase-18581.master.001.patch, > hbase-18581.master.002.patch > > > * calls to methods getLowestLocalityRegionServer() & > getLeastLoadedTopServerForRegion() got removed in HBASE-18164 > * call to calculateRegionServerLocalities() got removed in HBASE-15486 > * Some other minor improvements -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20914) Trim Master memory usage
[ https://issues.apache.org/jira/browse/HBASE-20914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20914: -- Component/s: Balancer > Trim Master memory usage > > > Key: HBASE-20914 > URL: https://issues.apache.org/jira/browse/HBASE-20914 > Project: HBase > Issue Type: Sub-task > Components: Balancer, master >Reporter: stack >Assignee: stack >Priority: Major > Labels: balancer > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.2 > > Attachments: HBASE-20914.branch-2.0.001.patch, Screen Shot 2018-07-19 > at 1.20.23 PM.png, Screen Shot 2018-07-19 at 1.20.23 PM.png, Screen Shot > 2018-07-19 at 1.38.56 PM.png, Screen Shot 2018-07-19 at 1.38.56 PM.png, > Screen Shot 2018-07-19 at 2.22.42 PM.png, Screen Shot 2018-07-19 at 2.22.42 > PM.png, Screen Shot 2018-07-19 at 2.43.42 PM.png, Screen Shot 2018-07-19 at > 2.43.42 PM.png > > > While working on the parent issue, looking at a heap from a Master tha was > running ~650 servers and > 300k regions, I tripped over some silly items in > the heap: > 1. Balancer has a regions x server matrix which takes up 18% of the Master > heap according to jxray and 40% according to eclipse. Looks like the matrix > should be regions x racks which would be much smaller (Issue came in with > HBASE-18164 Fast locality computation in balancer -Added new > LocalityCostFunction and LocalityCandidateGenerator ..). See !Screen Shot > 2018-07-19 at 1.20.23 PM.png! !Screen Shot 2018-07-19 at 1.38.56 PM.png! > 2. Duplicate Strings make up ~5% of the Master heap. Of these, ServerName > seems to be the font. Interesting is report that there 54k instances of > ServerName in this heap though there are only 650 Servers. See !Screen Shot > 2018-07-19 at 2.22.42 PM.png! > 3. ArrayDequeue initializes its internal elements array with 16 elements. We > use this in a few places. In Procedures, of which there are many in this > heap, we near never make use of this array. See !Screen Shot 2018-07-19 at > 2.43.42 PM.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20768) should we bypass the RegionLocationFinder#scheduleFullRefresh execution when master has not initialized
[ https://issues.apache.org/jira/browse/HBASE-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20768: -- Labels: balancer (was: ) > should we bypass the RegionLocationFinder#scheduleFullRefresh execution when > master has not initialized > --- > > Key: HBASE-20768 > URL: https://issues.apache.org/jira/browse/HBASE-20768 > Project: HBase > Issue Type: Improvement > Components: Balancer >Reporter: chenxu >Priority: Major > Labels: balancer > Attachments: HBASE-20768-master-v1.patch > > > Our KYLIN cluster has about 300K Regions, when master startup, It takes a > long time to do RegionLocationFinder#scheduleFullRefresh. > During this period, CUBE cannot be built, because master has not initialized. > Although we can ignore locality factor through HBASE-18478, but i think it > would be better if we bypass the RegionLocationFinder#scheduleFullRefresh > until the master initialized -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-18946) Stochastic load balancer assigns replica regions to the same RS
[ https://issues.apache.org/jira/browse/HBASE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-18946: -- Labels: balancer region_replica (was: region_replica) > Stochastic load balancer assigns replica regions to the same RS > --- > > Key: HBASE-18946 > URL: https://issues.apache.org/jira/browse/HBASE-18946 > Project: HBase > Issue Type: Bug > Components: Balancer >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: stack >Priority: Major > Labels: balancer, region_replica > Fix For: 2.0.0-beta-1, 2.0.0 > > Attachments: HBASE-18946.master.001.patch, > HBASE-18946.master.002.patch, HBASE-18946.master.003.patch, > HBASE-18946.master.004.patch, HBASE-18946.master.005.patch, > HBASE-18946.master.006.patch, HBASE-18946.master.007.patch, > HBASE-18946.master.008.patch, HBASE-18946.master.009.patch, > HBASE-18946.master.010.patch, HBASE-18946.master.011.patch, > HBASE-18946.master.012.patch, HBASE-18946.patch, HBASE-18946.patch, > HBASE-18946_2.patch, HBASE-18946_2.patch, HBASE-18946_simple_7.patch, > HBASE-18946_simple_8.patch, TestRegionReplicasWithRestartScenarios.java > > > Trying out region replica and its assignment I can see that some times the > default LB Stocahstic load balancer assigns replica regions to the same RS. > This happens when we have 3 RS checked in and we have a table with 3 > replicas. When a RS goes down then the replicas being assigned to same RS is > acceptable but the case when we have enough RS to assign this behaviour is > undesirable and does not solve the purpose of replicas. > [~huaxiang] and [~enis]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-18946) Stochastic load balancer assigns replica regions to the same RS
[ https://issues.apache.org/jira/browse/HBASE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-18946: -- Component/s: Balancer > Stochastic load balancer assigns replica regions to the same RS > --- > > Key: HBASE-18946 > URL: https://issues.apache.org/jira/browse/HBASE-18946 > Project: HBase > Issue Type: Bug > Components: Balancer >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: stack >Priority: Major > Labels: region_replica > Fix For: 2.0.0-beta-1, 2.0.0 > > Attachments: HBASE-18946.master.001.patch, > HBASE-18946.master.002.patch, HBASE-18946.master.003.patch, > HBASE-18946.master.004.patch, HBASE-18946.master.005.patch, > HBASE-18946.master.006.patch, HBASE-18946.master.007.patch, > HBASE-18946.master.008.patch, HBASE-18946.master.009.patch, > HBASE-18946.master.010.patch, HBASE-18946.master.011.patch, > HBASE-18946.master.012.patch, HBASE-18946.patch, HBASE-18946.patch, > HBASE-18946_2.patch, HBASE-18946_2.patch, HBASE-18946_simple_7.patch, > HBASE-18946_simple_8.patch, TestRegionReplicasWithRestartScenarios.java > > > Trying out region replica and its assignment I can see that some times the > default LB Stocahstic load balancer assigns replica regions to the same RS. > This happens when we have 3 RS checked in and we have a table with 3 > replicas. When a RS goes down then the replicas being assigned to same RS is > acceptable but the case when we have enough RS to assign this behaviour is > undesirable and does not solve the purpose of replicas. > [~huaxiang] and [~enis]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20740) StochasticLoadBalancer should consider CoprocessorService request factor when computing cost
[ https://issues.apache.org/jira/browse/HBASE-20740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20740: -- Labels: balancer (was: ) > StochasticLoadBalancer should consider CoprocessorService request factor when > computing cost > > > Key: HBASE-20740 > URL: https://issues.apache.org/jira/browse/HBASE-20740 > Project: HBase > Issue Type: Improvement > Components: Balancer >Reporter: chenxu >Assignee: chenxu >Priority: Major > Labels: balancer > Fix For: 3.0.0 > > Attachments: 20740-master-v2.patch, HBASE-20740-master-v1.patch, > HBASE-20740-master-v3.patch > > > When compute region load cost, ReadRequest, WriteRequest, MemStoreSize and > StoreFileSize are considered, But CoprocessorService requests are ignored. In > our KYLIN cluster, there only have CoprocessorService requests, and the > cluster sometimes unbalanced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20643) Getting HDFSBlockDist in Master by querying RegionServers
[ https://issues.apache.org/jira/browse/HBASE-20643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20643: -- Labels: balancer (was: ) > Getting HDFSBlockDist in Master by querying RegionServers > - > > Key: HBASE-20643 > URL: https://issues.apache.org/jira/browse/HBASE-20643 > Project: HBase > Issue Type: Improvement > Components: Balancer >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Labels: balancer > Fix For: 1.5.0, 2.3.0 > > > Region locality information is needed by the balancer to generate region > plans. Computing HDFSBlockDistribution is expensive on larger clusters and > adds load to the NameNode. This also needs to be recomputed on a master > restart. The proposal is to get the HDFSBlockDistribution from the > RegionServers instead of computing it in Master. RS already has this > information and we could just reuse it by querying it. RS already passes > dataLocality info via RegionLoad today. > Proposed Implementation: This is a high-level overview. > # A RegionServer API has to be added which will return HDFSBlockDistribution > for all the regions it hosts. RS already has this info. Since ClusterStatus > has already become bulky and we don’t need updated locality so fast, it’s > better to have another API rather than add this to RegionLoad and pass it > along with RSReport. > # Master will have a Chore to query all RegionServers and will cache the > HDFSBlockDistribution for those regions. This is easy and quick. Admins can > tune the frequency based on size of the cluster. On a ~90 nodes cluster with > 500k regions and a prototype implementation and no load, it took about 5 > seconds to get all HDFSBlockDistribution from RS. > # The cache will be an extension of RegionLocationFinder (subclass), if > needed to keep the implementation simple. Probably will get clear with > implementation. > # Balancer will use the new cache to get all HDFSBlockDistribution. If there > is a new region and Chore didn’t get the block distribution from RS during > its previous run, then it will be computed by RegionLocationFinder the same > way it has been done now. If the Chore runs more frequently like every hour, > then this recomputation will be drastically reduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20791) RSGroupBasedLoadBalancer#setClusterMetrics should pass ClusterMetrics to its internalBalancer
[ https://issues.apache.org/jira/browse/HBASE-20791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20791: -- Labels: balancer (was: ) > RSGroupBasedLoadBalancer#setClusterMetrics should pass ClusterMetrics to its > internalBalancer > - > > Key: HBASE-20791 > URL: https://issues.apache.org/jira/browse/HBASE-20791 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 3.0.0, 2.0.0 >Reporter: chenxu >Assignee: chenxu >Priority: Major > Labels: balancer > Fix For: 3.0.0, 2.2.0 > > Attachments: 20791-master-v2.patch, HBASE-20791-branch-2-v1.patch, > HBASE-20791-master-v1.patch, HBASE-20791-master-v3.patch, > HBASE-20791-master-v4.patch > > > RSGroupBasedLoadBalancer#setClusterMetrics should pass ClusterMetrics to it’s > internalBalancer, Or the StochasticLoadBalancer(internal balancer) will lose > it's Up-to-date RegionLoads info, and effect the balance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20791) RSGroupBasedLoadBalancer#setClusterMetrics should pass ClusterMetrics to its internalBalancer
[ https://issues.apache.org/jira/browse/HBASE-20791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-20791: -- Component/s: Balancer > RSGroupBasedLoadBalancer#setClusterMetrics should pass ClusterMetrics to its > internalBalancer > - > > Key: HBASE-20791 > URL: https://issues.apache.org/jira/browse/HBASE-20791 > Project: HBase > Issue Type: Bug > Components: Balancer, rsgroup >Affects Versions: 3.0.0, 2.0.0 >Reporter: chenxu >Assignee: chenxu >Priority: Major > Labels: balancer > Fix For: 3.0.0, 2.2.0 > > Attachments: 20791-master-v2.patch, HBASE-20791-branch-2-v1.patch, > HBASE-20791-master-v1.patch, HBASE-20791-master-v3.patch, > HBASE-20791-master-v4.patch > > > RSGroupBasedLoadBalancer#setClusterMetrics should pass ClusterMetrics to it’s > internalBalancer, Or the StochasticLoadBalancer(internal balancer) will lose > it's Up-to-date RegionLoads info, and effect the balance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
