[jira] [Commented] (HBASE-18649) Deprecate KV Usage in MR to move to Cells in 3.0
[ https://issues.apache.org/jira/browse/HBASE-18649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176058#comment-16176058 ] Chia-Ping Tsai commented on HBASE-18649: The v3 patch is stale. Would you please rebase it? > Deprecate KV Usage in MR to move to Cells in 3.0 > > > Key: HBASE-18649 > URL: https://issues.apache.org/jira/browse/HBASE-18649 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 2.0.0-alpha-2 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0, 3.0.0, 2.1.0 > > Attachments: HBASE-18649_branch-2.patch, HBASE-18649_master_2.patch, > HBASE-18649_master_3.patch, HBASE-18649_master.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15109) HM/RS failed to start when "fs.hdfs.impl.disable.cache" is set to true
[
https://issues.apache.org/jira/browse/HBASE-15109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176077#comment-16176077
]
Yechao Chen commented on HBASE-15109:
-
we met the same problem in branch 1.1.x， seems this patch need aply to
branch-1.1,branch-1.2,branch-1.3.
mind i create a new jira apply this patch to othe branches?
this is our error log:
bq. 2017-09-22 10:50:20,053 FATAL [regionserver/x-y2/a.b.c.d:60020]
regionserver.HRegionServer: ABORTING region server x-y2,60020,1506048613148:
Unhandled: Failed suppression of fs shutdown hook:
org.apache.hadoop.fs.FileSystem$Cache$ClientFinalizer@5d9559db
java.lang.RuntimeException: Failed suppression of fs shutdown hook:
org.apache.hadoop.fs.FileSystem$Cache$ClientFinalizer@5d9559db
at
org.apache.hadoop.hbase.regionserver.ShutdownHook.suppressHdfsShutdownHook(ShutdownHook.java:204)
at
org.apache.hadoop.hbase.regionserver.ShutdownHook.install(ShutdownHook.java:84)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:882)
at java.lang.Thread.run(Thread.java:745)
> HM/RS failed to start when "fs.hdfs.impl.disable.cache" is set to true
> --
>
> Key: HBASE-15109
> URL: https://issues.apache.org/jira/browse/HBASE-15109
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Pankaj Kumar
>Assignee: Pankaj Kumar
>Priority: Critical
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-15109-branch-1.patch, HBASE-15109.patch,
> HBASE-15109.patch, HBASE-15109-V2.patch
>
>
> HMaster failed to start during installing ShutdownHook when
> "fs.hdfs.impl.disable.cache" is set to true.
> {noformat}
> 2016-10-10 10:33:28,367 FATAL [master/HOST-10-18-106-146/10.18.106.146:16000]
> master.HMaster: Unhandled: Failed suppression of fs shutdown hook:
> org.apache.hadoop.fs.FileSystem$Cache$ClientFinalizer@19a003b4
> java.lang.RuntimeException: Failed suppression of fs shutdown hook:
> org.apache.hadoop.fs.FileSystem$Cache$ClientFinalizer@19a003b4
> at
> org.apache.hadoop.hbase.regionserver.ShutdownHook.suppressHdfsShutdownHook(ShutdownHook.java:204)
> at
> org.apache.hadoop.hbase.regionserver.ShutdownHook.install(ShutdownHook.java:84)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:950)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> And RegionServer is in blocking state until a master is available,
> {noformat}
> "regionserver/HOST-10-18-106-146/10.18.106.146:16020" #17 prio=5 os_prio=0
> tid=0x00e4e800 nid=0xdc38 in Object.wait() [0x7f329dac6000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at
> org.apache.hadoop.hbase.zookeeper.ZooKeeperNodeTracker.blockUntilAvailable(ZooKeeperNodeTracker.java:159)
> - locked <0xae25c0c8> (a
> org.apache.hadoop.hbase.zookeeper.MasterAddressTracker)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.blockAndCheckIfStopped(HRegionServer.java:870)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.initializeZooKeeper(HRegionServer.java:809)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.preRegistrationInitialization(HRegionServer.java:783)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:943)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> During installation, first time it will try to suppress the HDFS shutdownhook
> by removing the hdfsclientfinalizer from HDFS. Since
> fs.hdfs.impl.disable.cache is enabled, so removal will be unsuccessful from
> HDFS (FS is not cached) and RuntimeException will be thrown with "Failed
> suppression of fs shutdown hook" message.
> In ShutdownHook,
> {code}
> if (!fsShutdownHooks.containsKey(hdfsClientFinalizer) &&
> !ShutdownHookManager.deleteShutdownHook(hdfsClientFinalizer)) {
> throw new RuntimeException("Failed suppression of fs shutdown hook: " +
> hdfsClientFinalizer);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
Yechao Chen created HBASE-18862: --- Summary: apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 Key: HBASE-18862 URL: https://issues.apache.org/jira/browse/HBASE-18862 Project: HBase Issue Type: Bug Reporter: Yechao Chen Assignee: Yechao Chen HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176080#comment-16176080 ] Yechao Chen commented on HBASE-18862: - HBASE-15109 just change in branch1.4 and branch-2 we met the same problem in branch 1.1.x，make HBASE-15109 apply to branch-1.1,branch-1.2,branch-1.3. our error log: 2017-09-22 10:50:20,053 FATAL [regionserver/x-y2/a.b.c.d:60020] regionserver.HRegionServer: ABORTING region server x-y2,60020,1506048613148: Unhandled: Failed suppression of fs shutdown hook: org.apache.hadoop.fs.FileSystem$Cache$ClientFinalizer@5d9559db java.lang.RuntimeException: Failed suppression of fs shutdown hook: org.apache.hadoop.fs.FileSystem$Cache$ClientFinalizer@5d9559db at org.apache.hadoop.hbase.regionserver.ShutdownHook.suppressHdfsShutdownHook(ShutdownHook.java:204) at org.apache.hadoop.hbase.regionserver.ShutdownHook.install(ShutdownHook.java:84) at org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:882) at java.lang.Thread.run(Thread.java:745) > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug >Reporter: Yechao Chen >Assignee: Yechao Chen > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yechao Chen updated HBASE-18862: Affects Version/s: 1.3.1 1.2.6 1.1.12 > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yechao Chen updated HBASE-18862: Priority: Critical (was: Major) Component/s: regionserver > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yechao Chen updated HBASE-18862: Attachment: HBASE-18862-branch-1.patch > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > Attachments: HBASE-18862-branch-1.patch > > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yechao Chen updated HBASE-18862: Fix Version/s: 1.1.13 1.2.7 1.3.2 > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > Fix For: 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18862-branch-1.patch > > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176098#comment-16176098 ] Yechao Chen commented on HBASE-18862: - [~tedyu] [~pankaj2461] mind have a look this small patch ? thanks > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > Fix For: 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18862-branch-1.patch > > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[
https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176105#comment-16176105
]
Hadoop QA commented on HBASE-18862:
---
| (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 12s{color}
| {color:red} HBASE-18862 does not apply to branch-1. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18862 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12888459/HBASE-18862-branch-1.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/8738/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
> -
>
> Key: HBASE-18862
> URL: https://issues.apache.org/jira/browse/HBASE-18862
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 1.3.1, 1.2.6, 1.1.12
>Reporter: Yechao Chen
>Assignee: Yechao Chen
>Priority: Critical
> Fix For: 1.3.2, 1.2.7, 1.1.13
>
> Attachments: HBASE-18862-branch-1.patch
>
>
> HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yechao Chen updated HBASE-18862: Status: Patch Available (was: Open) > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.1.12, 1.2.6, 1.3.1 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > Fix For: 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18862-branch-1.patch > > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yechao Chen updated HBASE-18862: Attachment: HBASE-18862-branch-1.3.patch > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > Fix For: 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18862-branch-1.1.patch, > HBASE-18862-branch-1.2.patch, HBASE-18862-branch-1.3.patch, > HBASE-18862-branch-1.patch > > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176113#comment-16176113 ] Yechao Chen commented on HBASE-18862: - retry Hadoop QA > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > Fix For: 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18862-branch-1.1.patch, > HBASE-18862-branch-1.2.patch, HBASE-18862-branch-1.3.patch, > HBASE-18862-branch-1.patch > > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yechao Chen updated HBASE-18862: Attachment: HBASE-18862-branch-1.2.patch > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > Fix For: 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18862-branch-1.1.patch, > HBASE-18862-branch-1.2.patch, HBASE-18862-branch-1.3.patch, > HBASE-18862-branch-1.patch > > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yechao Chen updated HBASE-18862: Attachment: HBASE-18862-branch-1.1.patch > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > Fix For: 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18862-branch-1.1.patch, > HBASE-18862-branch-1.2.patch, HBASE-18862-branch-1.3.patch, > HBASE-18862-branch-1.patch > > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16769) Deprecate/remove PB references from MasterObserver and RegionServerObserver
[
https://issues.apache.org/jira/browse/HBASE-16769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176121#comment-16176121
]
Hadoop QA commented on HBASE-16769:
---
| (/) *{color:green}+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: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 5 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
38s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
50s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
55s{color} | {color:green} master passed {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} 1m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
44s{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
2s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
39m 31s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 92m
40s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
36s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m
43s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
48s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}171m 12s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-16769 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12888441/HBASE-16769_V4.patch |
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux efd2303e65a0 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-
[jira] [Commented] (HBASE-18651) Let ChaosMonkeyRunner expose the chaos monkey runner it creates
[ https://issues.apache.org/jira/browse/HBASE-18651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176137#comment-16176137 ] Hudson commented on HBASE-18651: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3757 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3757/]) HBASE-18651 Let ChaosMonkeyRunner expose the chaos monkey runner it (mdrob: rev 5f238b3ef46e7d5f31a9fb2dfff0111085af835d) * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/test/IntegrationTestMonkeys.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/util/ChaosMonkeyRunner.java * (add) hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/util/Monkeys.java > Let ChaosMonkeyRunner expose the chaos monkey runner it creates > --- > > Key: HBASE-18651 > URL: https://issues.apache.org/jira/browse/HBASE-18651 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Reid Chan > Fix For: 3.0.0, 2.0.0-alpha-4 > > Attachments: HBASE-18651.master.001.patch, > HBASE-18651.master.002.patch, HBASE-18651.master.003.patch, > HBASE-18651.master.004.patch, HBASE-18651.master.005.patch, > HBASE-18651.master.006.patch > > > Currently ChaosMonkeyRunner#main() instantiates ChaosMonkeyRunner without > keeping track of the instance. > This poses some challenge when ChaosMonkeyRunner is used programmatically > because the caller cannot get hold of the runner. > As [~mdrob] suggested, we should expose the chaos monkey runner. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176147#comment-16176147
]
Hadoop QA commented on HBASE-18847:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
24s{color} | {color:blue} Docker mode activated. {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
48s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
38s{color} | {color:green} branch-1.2 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
35s{color} | {color:green} branch-1.2 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
3s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
0s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
56s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
35s{color} | {color:green} branch-1.2 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} branch-1.2 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
33s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
33s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{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
19s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 17s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}419m 32s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 3m
53s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}462m 19s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.balancer.TestStochasticLoadBalancer |
| | hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionW
[jira] [Updated] (HBASE-18837) HTableMultiplexer behavior during regions split
[
https://issues.apache.org/jira/browse/HBASE-18837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reid Chan updated HBASE-18837:
--
Description:
HTableMultiplexer class mentions following in the javadoc : "If any queue is
full, the HTableMultiplexer starts to drop the Put requests for that particular
queue."
This could be improved by replacing following code in
HTableMultiplexer.resubmitFailedPut() method :
{code:title=HTableMultiplexer}
try {
succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
retryCount);
} finally {
FlushWorker.this.getRetryInQueue().decrementAndGet();
if (!succ) {
FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
}
}
{code}
With :
{code}
try {
succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
retryCount);
if (!succ) {
if (!resubmitFailedPut(ps, oldLoc)) {
FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
}
}
} finally {
FlushWorker.this.getRetryInQueue().decrementAndGet();
}
{code}
was:
HTableMultiplexer class mentions following in the javadoc : "If any queue is
full, the HTableMultiplexer starts to drop the Put requests for that particular
queue."
This could be improved by replacing following code in
HTableMultiplexer.resubmitFailedPut() method :
try {
succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
retryCount);
} finally {
FlushWorker.this.getRetryInQueue().decrementAndGet();
if (!succ) {
FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
}
}
With :
try {
succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
retryCount);
if (!succ) {
if (!resubmitFailedPut(ps, oldLoc)) {
FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
}
}
} finally {
FlushWorker.this.getRetryInQueue().decrementAndGet();
}
> HTableMultiplexer behavior during regions split
> ---
>
> Key: HBASE-18837
> URL: https://issues.apache.org/jira/browse/HBASE-18837
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 1.1.2
>Reporter: chausson
>Priority: Minor
>
> HTableMultiplexer class mentions following in the javadoc : "If any queue is
> full, the HTableMultiplexer starts to drop the Put requests for that
> particular queue."
> This could be improved by replacing following code in
> HTableMultiplexer.resubmitFailedPut() method :
> {code:title=HTableMultiplexer}
> try {
> succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
> retryCount);
> } finally {
> FlushWorker.this.getRetryInQueue().decrementAndGet();
> if (!succ) {
> FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
> }
> }
> {code}
> With :
> {code}
> try {
> succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
> retryCount);
> if (!succ) {
> if (!resubmitFailedPut(ps, oldLoc)) {
>
> FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
> }
> }
> } finally {
> FlushWorker.this.getRetryInQueue().decrementAndGet();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176156#comment-16176156
]
Chia-Ping Tsai commented on HBASE-18847:
Our QA are messed up now...:((see HBASE-18645). Please retry your patch. Thanks.
> remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176158#comment-16176158
]
Anoop Sam John commented on HBASE-18847:
Patch LGTM. Given the reasoning, strict sync check and logging only once is
not really needed.
> remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18837) HTableMultiplexer behavior during regions split
[
https://issues.apache.org/jira/browse/HBASE-18837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176168#comment-16176168
]
Reid Chan commented on HBASE-18837:
---
{code}
if (!succ) {
if (!resubmitFailedPut(ps, oldLoc)) {
FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
}
}
{code}
It potentially leads to a recursive call on {{resubmitFailedPut(ps, oldLoc)}}
methods, as long as this put gets failed caused by some unexpected situations,
resulting in StackOverFlow or OutOfMemory exception whichever comes first.
> HTableMultiplexer behavior during regions split
> ---
>
> Key: HBASE-18837
> URL: https://issues.apache.org/jira/browse/HBASE-18837
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 1.1.2
>Reporter: chausson
>Priority: Minor
>
> HTableMultiplexer class mentions following in the javadoc : "If any queue is
> full, the HTableMultiplexer starts to drop the Put requests for that
> particular queue."
> This could be improved by replacing following code in
> HTableMultiplexer.resubmitFailedPut() method :
> {code:title=HTableMultiplexer}
> try {
> succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
> retryCount);
> } finally {
> FlushWorker.this.getRetryInQueue().decrementAndGet();
> if (!succ) {
> FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
> }
> }
> {code}
> With :
> {code}
> try {
> succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
> retryCount);
> if (!succ) {
> if (!resubmitFailedPut(ps, oldLoc)) {
>
> FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
> }
> }
> } finally {
> FlushWorker.this.getRetryInQueue().decrementAndGet();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18837) HTableMultiplexer behavior during regions split
[
https://issues.apache.org/jira/browse/HBASE-18837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176168#comment-16176168
]
Reid Chan edited comment on HBASE-18837 at 9/22/17 9:32 AM:
{code}
if (!succ) {
if (!resubmitFailedPut(ps, oldLoc)) {
FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
}
}
{code}
It potentially leads to a recursive call on {{resubmitFailedPut(ps, oldLoc)}}
methods, as long as this put gets failed caused by some unexpected situations,
resulting in StackOverFlow or OutOfMemory exception whichever comes first.
was (Author: reidchan):
{code}
if (!succ) {
if (!resubmitFailedPut(ps, oldLoc)) {
FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
}
}
{code}
It potentially leads to a recursive call on {{resubmitFailedPut(ps, oldLoc)}}
methods, as long as this put gets failed caused by some unexpected situations,
resulting in StackOverFlow or OutOfMemory exception whichever comes first.
> HTableMultiplexer behavior during regions split
> ---
>
> Key: HBASE-18837
> URL: https://issues.apache.org/jira/browse/HBASE-18837
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 1.1.2
>Reporter: chausson
>Priority: Minor
>
> HTableMultiplexer class mentions following in the javadoc : "If any queue is
> full, the HTableMultiplexer starts to drop the Put requests for that
> particular queue."
> This could be improved by replacing following code in
> HTableMultiplexer.resubmitFailedPut() method :
> {code:title=HTableMultiplexer}
> try {
> succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
> retryCount);
> } finally {
> FlushWorker.this.getRetryInQueue().decrementAndGet();
> if (!succ) {
> FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
> }
> }
> {code}
> With :
> {code}
> try {
> succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
> retryCount);
> if (!succ) {
> if (!resubmitFailedPut(ps, oldLoc)) {
>
> FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
> }
> }
> } finally {
> FlushWorker.this.getRetryInQueue().decrementAndGet();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18837) HTableMultiplexer behavior during regions split
[
https://issues.apache.org/jira/browse/HBASE-18837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176187#comment-16176187
]
Reid Chan commented on HBASE-18837:
---
Btw, you can provide a patch containing unit test, then wait/ping for a review,
if you make sure your way works.
> HTableMultiplexer behavior during regions split
> ---
>
> Key: HBASE-18837
> URL: https://issues.apache.org/jira/browse/HBASE-18837
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 1.1.2
>Reporter: chausson
>Priority: Minor
>
> HTableMultiplexer class mentions following in the javadoc : "If any queue is
> full, the HTableMultiplexer starts to drop the Put requests for that
> particular queue."
> This could be improved by replacing following code in
> HTableMultiplexer.resubmitFailedPut() method :
> {code:title=HTableMultiplexer}
> try {
> succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
> retryCount);
> } finally {
> FlushWorker.this.getRetryInQueue().decrementAndGet();
> if (!succ) {
> FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
> }
> }
> {code}
> With :
> {code}
> try {
> succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut,
> retryCount);
> if (!succ) {
> if (!resubmitFailedPut(ps, oldLoc)) {
>
> FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
> }
> }
> } finally {
> FlushWorker.this.getRetryInQueue().decrementAndGet();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18863) spark over hbase snapshot
ulysses you created HBASE-18863:
---
Summary: spark over hbase snapshot
Key: HBASE-18863
URL: https://issues.apache.org/jira/browse/HBASE-18863
Project: HBase
Issue Type: Bug
Components: Client, snapshots, spark
Affects Versions: 1.2.0
Reporter: ulysses you
The configuration error in two method. First is ok, and second is wrong.
{code:java}
1.
val hConf = HBaseConfiguration.create()
// ignore some config
val hBaseRDD = sc.newAPIHadoopRDD(hConf,
classOf[TableSnapshotInputFormat],
classOf[org.apache.hadoop.hbase.io.ImmutableBytesWritable],
classOf[org.apache.hadoop.hbase.client.Result])
2.
val hConf = HBaseConfiguration.create()
val job = Job.getInstance(hConf)
val hBaseRDD = sc.newAPIHadoopRDD(job.getConfiguration,
classOf[TableSnapshotInputFormat],
classOf[org.apache.hadoop.hbase.io.ImmutableBytesWritable],
classOf[org.apache.hadoop.hbase.client.Result])
and the log:
Caused by: java.lang.ClassNotFoundException:
org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeCodec
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at
org.apache.hadoop.hbase.io.encoding.DataBlockEncoding.createEncoder(DataBlockEncoding.java:186)
... 21 more
{code}
I'm sure that I have upload jar with spark cmd -jars.
Is this a bug?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18775) Add a Global Read-Only property to turn off all writes for the cluster
[ https://issues.apache.org/jira/browse/HBASE-18775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176206#comment-16176206 ] Ashish Singhi commented on HBASE-18775: --- Can we add a coprocessor for this instead of adding the checks in the core code ? Some think like ReadOnlyClusterEnabler coprocessor which will extend BaseMasterAndRegionServer class and will throw exception in the pre hook of all the required DDL and DML operations. I think coprocessor based solution for this will be more better. > Add a Global Read-Only property to turn off all writes for the cluster > -- > > Key: HBASE-18775 > URL: https://issues.apache.org/jira/browse/HBASE-18775 > Project: HBase > Issue Type: Sub-task > Components: master, regionserver >Affects Versions: HBASE-18477 >Reporter: Zach York >Assignee: Zach York > Attachments: HBASE-18775.HBASE-18477.001.patch, > HBASE-18775.HBASE-18477.002.patch, HBASE-18775.HBASE-18477.003.patch, > HBASE-18775.HBASE-18477.004.patch > > > As part of HBASE-18477, we need a way to turn off all modification for a > cluster. This patch extends the read only mode used by replication to disable > all data and metadata operations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176208#comment-16176208 ] Yechao Chen commented on HBASE-18862: - by the way , if the patch name is xxx-xxx-branch-1.patch. this means the patch will be apply to branch-1? why not apply to branch-1.1,1.2.1.3 ? the patch apply to the branch by "Fix Version" or patch name? > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > Fix For: 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18862-branch-1.1.patch, > HBASE-18862-branch-1.2.patch, HBASE-18862-branch-1.3.patch, > HBASE-18862-branch-1.patch > > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176221#comment-16176221 ] Yu Li commented on HBASE-18862: --- bq. if the patch name is xxx-xxx-branch-1.patch. this means the patch will be apply to branch-1? Correct, and for branch-1.1, the patch should be named as HBASE-18862.branch-1.1.patch or so, including "branch-1.1" in its name. bq. the patch apply to the branch by "Fix Version" or patch name? HadoopQA checks patch name to decide which branch to apply it and run UT against. More relative topics please refer to our ref-guide: http://hbase.apache.org/book.html#developing > apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3 > - > > Key: HBASE-18862 > URL: https://issues.apache.org/jira/browse/HBASE-18862 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 1.3.1, 1.2.6, 1.1.12 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Critical > Fix For: 1.3.2, 1.2.7, 1.1.13 > > Attachments: HBASE-18862-branch-1.1.patch, > HBASE-18862-branch-1.2.patch, HBASE-18862-branch-1.3.patch, > HBASE-18862-branch-1.patch > > > HBASE-15109 should apply to branch-1.1,branch-1.2,branch-1.3 also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18775) Add a Global Read-Only property to turn off all writes for the cluster
[ https://issues.apache.org/jira/browse/HBASE-18775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176225#comment-16176225 ] Ashish Singhi commented on HBASE-18775: --- Instead of a read-only cluster configuration, did you think about my [this comment | https://issues.apache.org/jira/browse/HBASE-18477?focusedCommentId=16155007&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16155007] on the feature jira ? > Add a Global Read-Only property to turn off all writes for the cluster > -- > > Key: HBASE-18775 > URL: https://issues.apache.org/jira/browse/HBASE-18775 > Project: HBase > Issue Type: Sub-task > Components: master, regionserver >Affects Versions: HBASE-18477 >Reporter: Zach York >Assignee: Zach York > Attachments: HBASE-18775.HBASE-18477.001.patch, > HBASE-18775.HBASE-18477.002.patch, HBASE-18775.HBASE-18477.003.patch, > HBASE-18775.HBASE-18477.004.patch > > > As part of HBASE-18477, we need a way to turn off all modification for a > cluster. This patch extends the read only mode used by replication to disable > all data and metadata operations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18298) RegionServerServices Interface cleanup for CP expose
[ https://issues.apache.org/jira/browse/HBASE-18298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176231#comment-16176231 ] Anoop Sam John commented on HBASE-18298: bq.Yeah, name CoprocessorRSServices as CompressorRegionServerServices and method name should be getCompressorRegionServerServices U mean Coprocessor not Compressor right? bq.Or could we insert an immutable OnlineRegions? Or make a subinterface that adds the editing methods? I thought of making 2 interfaces with the base for the CP expose and the sub with adding the APIs to update the online regions.. Thought of going with smaller change :-).. Ya will do.. I think the 2 interface way is better than we have the API in the CP exposed and making that to throw Exception. Then every getter from the CP exposed API have to make a wrapper of this object and make the wrapper impl to throw Exception on the add/remove APIs. I prefer the simpler way of 2 interfaces. > RegionServerServices Interface cleanup for CP expose > > > Key: HBASE-18298 > URL: https://issues.apache.org/jira/browse/HBASE-18298 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18298.patch, HBASE-18298_V2.patch, > HBASE-18298_V3.patch, HBASE-18298_V4.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18649) Deprecate KV Usage in MR to move to Cells in 3.0
[ https://issues.apache.org/jira/browse/HBASE-18649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18649: --- Status: Open (was: Patch Available) > Deprecate KV Usage in MR to move to Cells in 3.0 > > > Key: HBASE-18649 > URL: https://issues.apache.org/jira/browse/HBASE-18649 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 2.0.0-alpha-2 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0, 3.0.0, 2.1.0 > > Attachments: HBASE-18649_branch-2.patch, HBASE-18649_master_2.patch, > HBASE-18649_master_3.patch, HBASE-18649_master.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18649) Deprecate KV Usage in MR to move to Cells in 3.0
[ https://issues.apache.org/jira/browse/HBASE-18649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18649: --- Status: Patch Available (was: Open) > Deprecate KV Usage in MR to move to Cells in 3.0 > > > Key: HBASE-18649 > URL: https://issues.apache.org/jira/browse/HBASE-18649 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 2.0.0-alpha-2 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0, 3.0.0, 2.1.0 > > Attachments: HBASE-18649_branch-2.patch, HBASE-18649_master_2.patch, > HBASE-18649_master_3.patch, HBASE-18649_master_5.patch, > HBASE-18649_master.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18649) Deprecate KV Usage in MR to move to Cells in 3.0
[ https://issues.apache.org/jira/browse/HBASE-18649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18649: --- Fix Version/s: 2.0.0-alpha-4 > Deprecate KV Usage in MR to move to Cells in 3.0 > > > Key: HBASE-18649 > URL: https://issues.apache.org/jira/browse/HBASE-18649 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 2.0.0-alpha-2 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0, 3.0.0, 2.1.0, 2.0.0-alpha-4 > > Attachments: HBASE-18649_branch-2.patch, HBASE-18649_master_2.patch, > HBASE-18649_master_3.patch, HBASE-18649_master_5.patch, > HBASE-18649_master.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18649) Deprecate KV Usage in MR to move to Cells in 3.0
[ https://issues.apache.org/jira/browse/HBASE-18649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18649: --- Attachment: HBASE-18649_master_5.patch Updated patch for master branch. The main difference is that we are not expecting the Cell to be of type ExtendedCell in the MR code instead the MapReduceCell is still of type ExtendedCell and the cell it wraps uses the CellUtil's newly added methods to make use of the ExtendedCell properties. (If you feel the new methods are not needed in CellUtl then we should move them to some MRUtil class). So the plan for branch-2 should be add the new CellSorrtReducer, CellSerialization to the code base and mark the KVSortReducer, KVSerialization as deprecated. This also applies to some of the mappers, reducers, and sorters inside the Import.java. The branch-2 code will be made to work with MapReduceCell only and we can mark things as incompatible change. Those who are using the KVSortREducer and KVSerialization in their custom job will still be able to run for branch-2. How ever if some one is using HFileOutptFormat2 of branch-2 (after this commit) he can be sure that internally we have already set the mapper value type to MapREduceCell and so we are safe. Pls give feedback on this. So that accordingly I can prepare a patch for branch-2 with a new subtask so that it is clear. > Deprecate KV Usage in MR to move to Cells in 3.0 > > > Key: HBASE-18649 > URL: https://issues.apache.org/jira/browse/HBASE-18649 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 2.0.0-alpha-2 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0, 3.0.0, 2.1.0, 2.0.0-alpha-4 > > Attachments: HBASE-18649_branch-2.patch, HBASE-18649_master_2.patch, > HBASE-18649_master_3.patch, HBASE-18649_master_5.patch, > HBASE-18649_master.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18298) RegionServerServices Interface cleanup for CP expose
[ https://issues.apache.org/jira/browse/HBASE-18298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-18298: --- Attachment: HBASE-18298_V5.patch Fixing all the comments > RegionServerServices Interface cleanup for CP expose > > > Key: HBASE-18298 > URL: https://issues.apache.org/jira/browse/HBASE-18298 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18298.patch, HBASE-18298_V2.patch, > HBASE-18298_V3.patch, HBASE-18298_V4.patch, HBASE-18298_V5.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18298) RegionServerServices Interface cleanup for CP expose
[
https://issues.apache.org/jira/browse/HBASE-18298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176274#comment-16176274
]
Anoop Sam John commented on HBASE-18298:
bq.How comes getRpcServer? Some CPs need this? I'd think CP is running in a RS.
We are already inside past the RPC. Why would a CP be meddling w/ RPC? Naughty
CP!
Ya I just overlooked it. I see RpcServerInterface been exposed so just kept
this method.. Seeing what is there in RpcServerInterface, we should not be
exposing this getter. RpcServerInterface (and now the abstract extension of
this RpcServer) been exposed for Phoenix to plugin custom impl. We have a
config for this ('hbase.rpc.server.impl')
Thanks for the reviews.
> RegionServerServices Interface cleanup for CP expose
>
>
> Key: HBASE-18298
> URL: https://issues.apache.org/jira/browse/HBASE-18298
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18298.patch, HBASE-18298_V2.patch,
> HBASE-18298_V3.patch, HBASE-18298_V4.patch, HBASE-18298_V5.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18645) Loads of tests timing out....
[ https://issues.apache.org/jira/browse/HBASE-18645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176286#comment-16176286 ] Sean Busbey commented on HBASE-18645: - If we go the revert approach, please do it in a new branch that we can remove when we're done. > Loads of tests timing out > - > > Key: HBASE-18645 > URL: https://issues.apache.org/jira/browse/HBASE-18645 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Critical > Attachments: HBASE-18645.master.001.patch, > HBASE-18645.master.001.patch > > > Whats up? Why are tests mostly timing out? When did it start? I can't seem to > make it happen locally so tough doing a bisect. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[
https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176299#comment-16176299
]
Abhishek Singh Chouhan commented on HBASE-18796:
[~apurtell] The addendum might not be correct solution to this problem and
might cause a problem elsewhere. I think we should hold on to committing that.
I had a bit more look into the behavior. Scan.next says that we should either
get values or we get null if the scanner is exhausted. This doesn't seem to be
the case hence we're getting the issue here.
In the client scanner
values = call(callable, caller, scannerTimeout, true);
we get a single element in the Result[] values array. Now we proceed to
Result[] resultsToAddToCache =
scanResultCache.addAndGet(values, callable.isHeartbeatMessage());
int numberOfCompleteRows =
scanResultCache.numberOfCompleteRows() - numberOfCompleteRowsBefore;
In CompleteScanResultCache#addAndGet we have the code:
{code}
Result last = results[results.length - 1];
if (last.mayHaveMoreCellsInRow()) {
if (partialResults.isEmpty()) {
partialResults.add(last);
return updateNumberOfCompleteResultsAndReturn(Arrays.copyOf(results,
results.length - 1));
}
{code}
here since results.length = 1 and last.mayHaveMoreCellsInRow() is true we add
the result we got into partialResults however the completed results is 0.
We end up in (have to look more into this part)
if (scan.getLimit() == 0 || scanExhausted(values)) {
closeScanner();
closed = true;
break;
}
and end up returning null to the client which should not be the case. We should
open another jira for this. Setting allowpartial in ConnectionImplementation
might be the wrong thing to do that has other side effects and might hide the
actual problem.
Someone with more familiarity on the partial scanning side should have more
insights. I'll dig into this more tomorrow. In the meantime if we want to just
fix the test we can add isTableEnabled() in the wait for split which would make
it more robust since checking just number of regions might be a false indicator
of successful split.
[~tedyu] [~apurtell] [~lhofhansl]
> Admin#isTableAvailable returns incorrect result before daughter regions are
> opened
> --
>
> Key: HBASE-18796
> URL: https://issues.apache.org/jira/browse/HBASE-18796
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0
>
> Attachments: HBASE-18796-addendum.branch-1.patch,
> HBASE-18796-addendum.master.patch, HBASE-18796.branch-1.001.patch,
> HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.002.patch,
> HBASE-18796.branch-1.003.patch, HBASE-18796.master.001.patch
>
>
> Admin#isTableAvailable checks if it can getServerName for the meta entries it
> reads. During the time of split server location are added to the meta entries
> in MetaTableAccessor#splitRegion although the description of the method says
> "Does not add the location information to the daughter regions since they are
> not open yet.". At this point during the split daughter regions are not
> actually open, so we can get to a state where parent is offline, daughters
> are not yet open but isTableAvailable returns true.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18649) Deprecate KV Usage in MR to move to Cells in 3.0
[
https://issues.apache.org/jira/browse/HBASE-18649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176330#comment-16176330
]
Hadoop QA commented on HBASE-18649:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {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 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
37s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
42s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
42s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
43s{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:red}-1{color} | {color:red} shadedjars {color} | {color:red} 3m
1s{color} | {color:red} patch has 10 errors when building our shaded downstream
artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 42s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
18s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
17s{color} | {color:red} hbase-common generated 1 new + 0 unchanged - 0 fixed =
1 total (was 0) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
20s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 6m 35s{color}
| {color:red} hbase-mapreduce in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m
25s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m
25s{color} | {color:red} The patch generated 1 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 76m 0s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.mapreduce.TestImportExport |
| | hadoop.hbase.mapreduce.TestWALPlayer |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18649 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12888480/HBASE-18649_master_5.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 4600374a3f4
[jira] [Commented] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176363#comment-16176363
]
Sean Busbey commented on HBASE-18847:
-
I manually restarted the precommit job. If that fails out again, I plan to run
through all the hfile tests locally before accepting the patch. Anything other
folks would like to see tested manually if precommit doesn't come back?
> remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176367#comment-16176367
]
Sean Busbey commented on HBASE-18847:
-
{quote}
-1 test4tests 0m 0s 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.
{quote}
I'd say we don't need a test for this, since we're just changing a lock around
a log message and we don't have any framework for testing changes to logging
currently.
> remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176374#comment-16176374
]
Chia-Ping Tsai commented on HBASE-18847:
bq. Anything other folks would like to see tested manually if precommit doesn't
come back?
Will run all tests locally.
> remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-13844) Move static helper methods from KeyValue into CellUtils
[
https://issues.apache.org/jira/browse/HBASE-13844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176382#comment-16176382
]
Chia-Ping Tsai commented on HBASE-13844:
[~andy7904] Consider loading the {{hbase_eclipse_formatter}} to your IDE. That
helps you layout the imports.
> Move static helper methods from KeyValue into CellUtils
> ---
>
> Key: HBASE-13844
> URL: https://issues.apache.org/jira/browse/HBASE-13844
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.0
>Reporter: Lars George
>Assignee: Andy Yang
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-13844.1.patch, HBASE-13844.2.patch,
> HBASE-13844.3.patch, HBASE-13844.branch-2.v0.patch,
> HBASE-13844.branch-2.v1.patch
>
>
> Add KeyValue.parseColumn() to CellUtils (also any other public static helper)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176385#comment-16176385
]
Sean Busbey commented on HBASE-18847:
-
bq. Will run all tests locally.
Fair enough. :) I'll spin up a new build box to grind on them. Might as well do
that in parallel to precommit.
> remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18864) NullPointerException thrown when adding rows to a table from peer cluster, table with replication factor other than 0 or 1
smita created HBASE-18864: - Summary: NullPointerException thrown when adding rows to a table from peer cluster, table with replication factor other than 0 or 1 Key: HBASE-18864 URL: https://issues.apache.org/jira/browse/HBASE-18864 Project: HBase Issue Type: Bug Components: hbase Affects Versions: 1.3.0 Reporter: smita Scenario: = add_peer create a table alter table with REPLICATION_SCOPE => '5' enable table replication login to peer cluster and try putting data to the table -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14217) Add Java access to Spark bulk load functionality
[ https://issues.apache.org/jira/browse/HBASE-14217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176454#comment-16176454 ] Jean-Marc Spaggiari commented on HBASE-14217: - No update? > Add Java access to Spark bulk load functionality > > > Key: HBASE-14217 > URL: https://issues.apache.org/jira/browse/HBASE-14217 > Project: HBase > Issue Type: Improvement >Reporter: Theodore michael Malaska >Assignee: Theodore michael Malaska >Priority: Minor > > HBASE-14150 added bulk load functionality for Scala users. This jira will > add the Java layer that will make this functionality accessable to Java > developers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18864) NullPointerException thrown when adding rows to a table from peer cluster, table with replication factor other than 0 or 1
[ https://issues.apache.org/jira/browse/HBASE-18864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] smita updated HBASE-18864: -- Description: Scenario: = add_peer create a table alter table with REPLICATION_SCOPE => '5' enable table replication login to peer cluster and try putting data to the table was: Scenario: = add_peer create a table alter table with REPLICATION_SCOPE => '5' enable table replication login to peer cluster and try putting data to the table > NullPointerException thrown when adding rows to a table from peer cluster, > table with replication factor other than 0 or 1 > -- > > Key: HBASE-18864 > URL: https://issues.apache.org/jira/browse/HBASE-18864 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.3.0 >Reporter: smita > > Scenario: > = > add_peer > create a table > alter table with REPLICATION_SCOPE => '5' > enable table replication > login to peer cluster and try putting data to the table -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18298) RegionServerServices Interface cleanup for CP expose
[
https://issues.apache.org/jira/browse/HBASE-18298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176482#comment-16176482
]
Hadoop QA commented on HBASE-18298:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
38s{color} | {color:blue} Docker mode activated. {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 5 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
34s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 8m
32s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
44s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
19s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
15s{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
12s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
39m 40s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
43s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 94m
16s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
57s{color} | {color:green} hbase-thrift in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
31s{color} | {color:green} hbase-endpoint in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
58s{color} | {color:green} hbase-examples in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
13s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}184m 52s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18298 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12888483/HBASE-18298_V5.patch |
| Optional Tests
[jira] [Commented] (HBASE-18807) Remove PB references from Observers for Quotas
[ https://issues.apache.org/jira/browse/HBASE-18807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176507#comment-16176507 ] Josh Elser commented on HBASE-18807: Argh, will fix the findbugs stuff today. > Remove PB references from Observers for Quotas > -- > > Key: HBASE-18807 > URL: https://issues.apache.org/jira/browse/HBASE-18807 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18807.001.branch-2.patch, > HBASE-18807.002.branch-2.patch, HBASE-18807.003.branch-2.patch > > > Break-out from the parent: > Same idea, just applied to the Observer methods for pre/post quota > operations. Requires changes to MasterQuotaManager and the QuotaSettings > implementations as some business logic is written on the PB objects directly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[
https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176508#comment-16176508
]
Abhishek Singh Chouhan commented on HBASE-18796:
Debugged this further. The issue was infact related to this part :)
{code}
if (scan.getLimit() == 0 || scanExhausted(values)) {
closeScanner();
closed = true;
break;
}
{code}
We're hitting scan.getLimit() == 0 which results in closing the scanner and
returning null. The problem being in
ConnectionImplementation#locateRegionInMeta we create the scan object outside
the retry loop and set s.setOneRowLimit() now during the first attempt we get
the row but with empty server location so we retry, however the limit has
already become 0 now because the scan returned a row during the first attempt,
now during the first attempt we incorrectly close the scan, hence getting the
TableNotFoundException. Let me put up an addendum that does this. Apologies for
the to and fro, took me some time to get to the bottom of this(hopefully :)).
> Admin#isTableAvailable returns incorrect result before daughter regions are
> opened
> --
>
> Key: HBASE-18796
> URL: https://issues.apache.org/jira/browse/HBASE-18796
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0
>
> Attachments: HBASE-18796-addendum.branch-1.patch,
> HBASE-18796-addendum.master.patch, HBASE-18796.branch-1.001.patch,
> HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.002.patch,
> HBASE-18796.branch-1.003.patch, HBASE-18796.master.001.patch
>
>
> Admin#isTableAvailable checks if it can getServerName for the meta entries it
> reads. During the time of split server location are added to the meta entries
> in MetaTableAccessor#splitRegion although the description of the method says
> "Does not add the location information to the daughter regions since they are
> not open yet.". At this point during the split daughter regions are not
> actually open, so we can get to a state where parent is offline, daughters
> are not yet open but isTableAvailable returns true.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[ https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Singh Chouhan updated HBASE-18796: --- Attachment: HBASE-18796-addendum.master.patch > Admin#isTableAvailable returns incorrect result before daughter regions are > opened > -- > > Key: HBASE-18796 > URL: https://issues.apache.org/jira/browse/HBASE-18796 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0 > > Attachments: HBASE-18796-addendum.branch-1.patch, > HBASE-18796-addendum.master.patch, HBASE-18796-addendum.master.patch, > HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.001.patch, > HBASE-18796.branch-1.002.patch, HBASE-18796.branch-1.003.patch, > HBASE-18796.master.001.patch > > > Admin#isTableAvailable checks if it can getServerName for the meta entries it > reads. During the time of split server location are added to the meta entries > in MetaTableAccessor#splitRegion although the description of the method says > "Does not add the location information to the daughter regions since they are > not open yet.". At this point during the split daughter regions are not > actually open, so we can get to a state where parent is offline, daughters > are not yet open but isTableAvailable returns true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[ https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Singh Chouhan updated HBASE-18796: --- Attachment: HBASE-18796-addendum.branch-1.patch > Admin#isTableAvailable returns incorrect result before daughter regions are > opened > -- > > Key: HBASE-18796 > URL: https://issues.apache.org/jira/browse/HBASE-18796 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0 > > Attachments: HBASE-18796-addendum.branch-1.patch, > HBASE-18796-addendum.branch-1.patch, HBASE-18796-addendum.master.patch, > HBASE-18796-addendum.master.patch, HBASE-18796.branch-1.001.patch, > HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.002.patch, > HBASE-18796.branch-1.003.patch, HBASE-18796.master.001.patch > > > Admin#isTableAvailable checks if it can getServerName for the meta entries it > reads. During the time of split server location are added to the meta entries > in MetaTableAccessor#splitRegion although the description of the method says > "Does not add the location information to the daughter regions since they are > not open yet.". At this point during the split daughter regions are not > actually open, so we can get to a state where parent is offline, daughters > are not yet open but isTableAvailable returns true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[ https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176571#comment-16176571 ] Ted Yu commented on HBASE-18796: Thanks for digging. The TestMultiRespectsLimits passes with new addendum. Suggest removing the old addendum for clarity. > Admin#isTableAvailable returns incorrect result before daughter regions are > opened > -- > > Key: HBASE-18796 > URL: https://issues.apache.org/jira/browse/HBASE-18796 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0 > > Attachments: HBASE-18796-addendum.branch-1.patch, > HBASE-18796-addendum.branch-1.patch, HBASE-18796-addendum.master.patch, > HBASE-18796-addendum.master.patch, HBASE-18796.branch-1.001.patch, > HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.002.patch, > HBASE-18796.branch-1.003.patch, HBASE-18796.master.001.patch > > > Admin#isTableAvailable checks if it can getServerName for the meta entries it > reads. During the time of split server location are added to the meta entries > in MetaTableAccessor#splitRegion although the description of the method says > "Does not add the location information to the daughter regions since they are > not open yet.". At this point during the split daughter regions are not > actually open, so we can get to a state where parent is offline, daughters > are not yet open but isTableAvailable returns true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[ https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Singh Chouhan updated HBASE-18796: --- Attachment: (was: HBASE-18796-addendum.master.patch) > Admin#isTableAvailable returns incorrect result before daughter regions are > opened > -- > > Key: HBASE-18796 > URL: https://issues.apache.org/jira/browse/HBASE-18796 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0 > > Attachments: HBASE-18796-addendum.branch-1.patch, > HBASE-18796-addendum.master.patch, HBASE-18796.branch-1.001.patch, > HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.002.patch, > HBASE-18796.branch-1.003.patch, HBASE-18796.master.001.patch > > > Admin#isTableAvailable checks if it can getServerName for the meta entries it > reads. During the time of split server location are added to the meta entries > in MetaTableAccessor#splitRegion although the description of the method says > "Does not add the location information to the daughter regions since they are > not open yet.". At this point during the split daughter regions are not > actually open, so we can get to a state where parent is offline, daughters > are not yet open but isTableAvailable returns true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[ https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Singh Chouhan updated HBASE-18796: --- Attachment: (was: HBASE-18796-addendum.branch-1.patch) > Admin#isTableAvailable returns incorrect result before daughter regions are > opened > -- > > Key: HBASE-18796 > URL: https://issues.apache.org/jira/browse/HBASE-18796 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0 > > Attachments: HBASE-18796-addendum.branch-1.patch, > HBASE-18796-addendum.master.patch, HBASE-18796.branch-1.001.patch, > HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.002.patch, > HBASE-18796.branch-1.003.patch, HBASE-18796.master.001.patch > > > Admin#isTableAvailable checks if it can getServerName for the meta entries it > reads. During the time of split server location are added to the meta entries > in MetaTableAccessor#splitRegion although the description of the method says > "Does not add the location information to the daughter regions since they are > not open yet.". At this point during the split daughter regions are not > actually open, so we can get to a state where parent is offline, daughters > are not yet open but isTableAvailable returns true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176577#comment-16176577
]
Dave Latham commented on HBASE-14247:
-
I still believe that committing this would have a significant risk of
introducing a regression of HBASE-9208. I would be (non-binding) -1 on doing
so until first improving the log cleaner or providing convincing evidence that
it would not happen.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247.master.001.patch,
> HBASE-14247.master.002.patch, HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18245) Handle failed server in RpcClient
[ https://issues.apache.org/jira/browse/HBASE-18245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-18245: --- Attachment: (was: 18245.v1.txt) > Handle failed server in RpcClient > - > > Key: HBASE-18245 > URL: https://issues.apache.org/jira/browse/HBASE-18245 > Project: HBase > Issue Type: Sub-task >Reporter: Ted Yu > Attachments: 18245.v2.txt, 18245.v3.txt > > > This task is to add support for failed server in RpcClient::GetConnection(). > FailedServers Java class would be ported to C++. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18862) apply HBASE-15109 to branch-1.1,branch-1.2,branch-1.3
[
https://issues.apache.org/jira/browse/HBASE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176604#comment-16176604
]
Hadoop QA commented on HBASE-18862:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 17m
45s{color} | {color:blue} Docker mode activated. {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
7s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
31s{color} | {color:green} branch-1.3 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} branch-1.3 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
46s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
50s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} branch-1.3 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} branch-1.3 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
31s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{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
17s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
18m 18s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
24s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}371m 30s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 3m
20s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}432m 32s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestRecoveredEdits |
| | hadoop.hbase.client.TestAdmin2 |
| | hadoop.hbase.util.TestHBaseFsck |
[jira] [Commented] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[
https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176613#comment-16176613
]
Hadoop QA commented on HBASE-18796:
---
| (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: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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
32s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s{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
55s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
38m 57s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
39s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 54m 50s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18796 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12888515/HBASE-18796-addendum.master.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux ebe28072294a 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 5f238b3 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/8743/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/8743/console |
| Powered by | Apache Yetus 0.4.0 http://ye
[jira] [Commented] (HBASE-18386) When the zookeeper host cannot be resolved, provide better error message
[
https://issues.apache.org/jira/browse/HBASE-18386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176623#comment-16176623
]
Ted Yu commented on HBASE-18386:
{code}
int zk_result = zoo_get(this->zk_, zk_node.c_str(), 0,
reinterpret_cast(buf->writableData()), &len,
nullptr);
if (zk_result != ZOK || len < 9) {
{code}
On top of checking return value, exception should be handled properly.
> When the zookeeper host cannot be resolved, provide better error message
>
>
> Key: HBASE-18386
> URL: https://issues.apache.org/jira/browse/HBASE-18386
> Project: HBase
> Issue Type: Sub-task
>Reporter: Ted Yu
>Priority: Minor
>
> Currently, when the zookeeper host cannot be resolved, we would see:
> {code}
> 2017-07-15 19:42:09,367:3811(0x7f9ee2ffd700):ZOO_ERROR@getaddrs@613:
> getaddrinfo: No such file or directory
> *** Aborted at 1500147729 (unix time) try "date -d @1500147729" if you are
> using GNU date ***
> PC: @ 0x6f4c28 zoo_get
> *** SIGSEGV (@0x260) received by PID 3811 (TID 0x7f9ee2ffd700) from PID 608;
> stack trace: ***
> @ 0x7f9eee0923d0 (unknown)
> @ 0x6f4c28 zoo_get
> @ 0xb4 hbase::LocationCache::ReadMetaLocation()
> @ 0x449ec4 std::_Function_handler<>::_M_invoke()
> @ 0x55ec12 wangle::ThreadPoolExecutor::runTask()
> @ 0x54dfca wangle::CPUThreadPoolExecutor::threadRun()
> @ 0x55f892 std::_Function_handler<>::_M_invoke()
> {code}
> There should be more intuitive error message so that user knows what to do
> next.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[
https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176634#comment-16176634
]
Hadoop QA commented on HBASE-18796:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
25s{color} | {color:blue} Docker mode activated. {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
16s{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_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
27s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
42s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
20s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
49s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
42s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
40s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
32s{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_144 {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
28s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
19s{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
49s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 53s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
47s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
46s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 53m 35s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f1cc2c |
| JIRA Issue | HBASE-18796 |
| JIRA Patch URL |
https://issues.apache.o
[jira] [Commented] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[ https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176642#comment-16176642 ] Andrew Purtell commented on HBASE-18796: Thanks for the new addendum. I couldn't commit the other because it didn't check out obviously. :-) This looks better. Trying again > Admin#isTableAvailable returns incorrect result before daughter regions are > opened > -- > > Key: HBASE-18796 > URL: https://issues.apache.org/jira/browse/HBASE-18796 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0 > > Attachments: HBASE-18796-addendum.branch-1.patch, > HBASE-18796-addendum.master.patch, HBASE-18796.branch-1.001.patch, > HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.002.patch, > HBASE-18796.branch-1.003.patch, HBASE-18796.master.001.patch > > > Admin#isTableAvailable checks if it can getServerName for the meta entries it > reads. During the time of split server location are added to the meta entries > in MetaTableAccessor#splitRegion although the description of the method says > "Does not add the location information to the daughter regions since they are > not open yet.". At this point during the split daughter regions are not > actually open, so we can get to a state where parent is offline, daughters > are not yet open but isTableAvailable returns true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18405) Track scope for HBase-Spark module
[ https://issues.apache.org/jira/browse/HBASE-18405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18405: Fix Version/s: (was: 2.0.0-beta-1) (was: 1.4.0) 1.5.0 2.1.0 3.0.0 > Track scope for HBase-Spark module > -- > > Key: HBASE-18405 > URL: https://issues.apache.org/jira/browse/HBASE-18405 > Project: HBase > Issue Type: Task > Components: spark >Reporter: Sean Busbey >Assignee: Sean Busbey > Fix For: 3.0.0, 2.1.0, 1.5.0 > > Attachments: Apache HBase - Apache Spark Integration Scope.pdf, > Apache HBase - Apache Spark Integration Scope - update 1.pdf > > > Start with [\[DISCUSS\] status of and plans for our hbase-spark integration > |https://lists.apache.org/thread.html/fd74ef9b9da77abf794664f06ea19c839fb3d543647fb29115081683@%3Cdev.hbase.apache.org%3E] > and formalize into a scope document for bringing this feature into a release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18861) [C++] Use boost::optional instead of std::experimental::optional
[
https://issues.apache.org/jira/browse/HBASE-18861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16175675#comment-16175675
]
Josh Elser edited comment on HBASE-18861 at 9/22/17 4:12 PM:
-
\+1 -- Patch looks good and works on local platforms that don't have C++17
support to include Centos 7.3 and Mac Sierra.
was (Author: phrocker):
+1 -- Patch looks good and works on local platforms that don't have C++17
support to include Centos 7.3 and Mac Sierra.
> [C++] Use boost::optional instead of std::experimental::optional
>
>
> Key: HBASE-18861
> URL: https://issues.apache.org/jira/browse/HBASE-18861
> Project: HBase
> Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Attachments: hbase-18861_v1.patch
>
>
> Our Marc Parisi indicates that using std::experimental is not prefered in
> production code, and causes compilation problems especially for compilers
> which do not have C++17 support.
> Our usage of {{std::experimental::optional}} is very small and can be easily
> replaced with {{boost::optional}}. We depend on boost anyways for other
> reasons.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18787) Fix the "dependencies connecting to an HBase cluster"
[
https://issues.apache.org/jira/browse/HBASE-18787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176653#comment-16176653
]
Sean Busbey commented on HBASE-18787:
-
+1
> Fix the "dependencies connecting to an HBase cluster"
> -
>
> Key: HBASE-18787
> URL: https://issues.apache.org/jira/browse/HBASE-18787
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18787.v0.patch
>
>
> {code}
> Minimally, an HBase client needs several libraries in its CLASSPATH when
> connecting to a cluster, including:
> commons-configuration (commons-configuration-1.6.jar)
> commons-lang3 (commons-lang3-3.6.jar)
> commons-logging (commons-logging-1.1.1.jar)
> hadoop-core (hadoop-core-1.0.0.jar)
> hbase (hbase-0.92.0.jar)
> log4j (log4j-1.2.16.jar)
> slf4j-api (slf4j-api-1.5.8.jar)
> slf4j-log4j (slf4j-log4j12-1.5.8.jar)
> zookeeper (zookeeper-3.4.2.jar)
> {code}
> The libraries listed in our docs are stale. Also, it may be better to say
> "*Minimally, an HBase client needs hbase-client module in its dependencies
> when connecting to a cluster*" rather than "*Minimally, an HBase client needs
> several libraries in its CLASSPATH when connecting to a cluster,
> including:*". I don't think newbie want to add all dependencies manually.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-17766) Generate Javadoc for hbase-spark module
[ https://issues.apache.org/jira/browse/HBASE-17766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-17766: Fix Version/s: (was: 2.0.0) 3.0.0 > Generate Javadoc for hbase-spark module > > > Key: HBASE-17766 > URL: https://issues.apache.org/jira/browse/HBASE-17766 > Project: HBase > Issue Type: Bug > Components: documentation, spark >Reporter: Yi Liang >Assignee: Yi Liang > Fix For: 3.0.0 > > Attachments: HBASE-17766-V1.patch, scaladoc.patch, spark-api.jpg, > user-api.jpg > > > Scala classes in hbase-spark module aren't showing up in our API docs nor > our internal API docs. see https://hbase.apache.org/apidocs/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-14160) backport hbase-spark module to branch-1 and branch-2
[ https://issues.apache.org/jira/browse/HBASE-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-14160: Description: Once the hbase-spark module gets polished a bit, we should backport to branch-1 and branch-2 so we can publish it sooner. needs (per previous discussion): * examples refactored into different module * user facing documentation * defined public API was: Once the hbase-spark module gets polished a bit, we should backport to branch-1 so we can publish it sooner. needs (per previous discussion): * examples refactored into different module * user facing documentation * defined public API > backport hbase-spark module to branch-1 and branch-2 > > > Key: HBASE-14160 > URL: https://issues.apache.org/jira/browse/HBASE-14160 > Project: HBase > Issue Type: New Feature > Components: spark >Affects Versions: 1.3.0 >Reporter: Sean Busbey > Fix For: 2.1.0, 1.5.0 > > > Once the hbase-spark module gets polished a bit, we should backport to > branch-1 and branch-2 so we can publish it sooner. > needs (per previous discussion): > * examples refactored into different module > * user facing documentation > * defined public API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-14160) backport hbase-spark module to branch-1 and branch-2
[ https://issues.apache.org/jira/browse/HBASE-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-14160: Summary: backport hbase-spark module to branch-1 and branch-2 (was: backport hbase-spark module to branch-1) > backport hbase-spark module to branch-1 and branch-2 > > > Key: HBASE-14160 > URL: https://issues.apache.org/jira/browse/HBASE-14160 > Project: HBase > Issue Type: New Feature > Components: spark >Affects Versions: 1.3.0 >Reporter: Sean Busbey > Fix For: 2.1.0, 1.5.0 > > > Once the hbase-spark module gets polished a bit, we should backport to > branch-1 so we can publish it sooner. > needs (per previous discussion): > * examples refactored into different module > * user facing documentation > * defined public API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14160) backport hbase-spark module to branch-1 and branch-2
[ https://issues.apache.org/jira/browse/HBASE-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176660#comment-16176660 ] Sean Busbey commented on HBASE-14160: - expanded title/description based on HBASE-18817 > backport hbase-spark module to branch-1 and branch-2 > > > Key: HBASE-14160 > URL: https://issues.apache.org/jira/browse/HBASE-14160 > Project: HBase > Issue Type: New Feature > Components: spark >Affects Versions: 1.3.0 >Reporter: Sean Busbey > Fix For: 2.1.0, 1.5.0 > > > Once the hbase-spark module gets polished a bit, we should backport to > branch-1 and branch-2 so we can publish it sooner. > needs (per previous discussion): > * examples refactored into different module > * user facing documentation > * defined public API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-14160) backport hbase-spark module to branch-1 and branch-2
[ https://issues.apache.org/jira/browse/HBASE-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-14160: Fix Version/s: 2.1.0 > backport hbase-spark module to branch-1 and branch-2 > > > Key: HBASE-14160 > URL: https://issues.apache.org/jira/browse/HBASE-14160 > Project: HBase > Issue Type: New Feature > Components: spark >Affects Versions: 1.3.0 >Reporter: Sean Busbey > Fix For: 2.1.0, 1.5.0 > > > Once the hbase-spark module gets polished a bit, we should backport to > branch-1 so we can publish it sooner. > needs (per previous discussion): > * examples refactored into different module > * user facing documentation > * defined public API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18176) add enforcer rule to make sure hbase-spark / scala aren't dependencies of unexpected modules
[ https://issues.apache.org/jira/browse/HBASE-18176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18176: Fix Version/s: (was: 2.0.0-alpha-2) > add enforcer rule to make sure hbase-spark / scala aren't dependencies of > unexpected modules > > > Key: HBASE-18176 > URL: https://issues.apache.org/jira/browse/HBASE-18176 > Project: HBase > Issue Type: Improvement > Components: build, spark >Reporter: Sean Busbey >Assignee: Mike Drob > Fix For: 3.0.0 > > Attachments: HBASE-18176.patch, HBASE-18176.v2.patch > > > We should have an enforcer plugin rule that makes sure we don't have scala > and/or hbase-spark showing up in new modules. (based on prior discussions > about limiting the scope of where those things show up in our classpath, esp > given scala's poor history on binary compatibility) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18175) Add hbase-spark integration test into hbase-spark-it
[ https://issues.apache.org/jira/browse/HBASE-18175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18175: Fix Version/s: (was: 2.0.0-alpha-2) > Add hbase-spark integration test into hbase-spark-it > > > Key: HBASE-18175 > URL: https://issues.apache.org/jira/browse/HBASE-18175 > Project: HBase > Issue Type: Test > Components: spark >Reporter: Yi Liang >Assignee: Yi Liang >Priority: Critical > Fix For: 3.0.0 > > Attachments: addendum-master.patch, hbase-18175-master-v2.patch, > hbase-18175-master-v3.patch, hbase-18175-master-v4.patch, > hbase-18175-master-v5.patch, hbase-18175-master-v6.patch, > hbase-18175-master-v7.patch, hbase-18175-master-v8.patch, > hbase-18175-master-v9.patch, hbase-18175-v1.patch > > > After HBASE-17574, all test under hbase-spark are regarded as unit test, and > this jira will add integration test of hbase-spark into hbase-it. This patch > run same tests as mapreduce.IntegrationTestBulkLoad, just change mapreduce to > spark. > test in Maven: > mvn verify -Dit.test=IntegrationTestSparkBulkLoad > test on cluster: > spark-submit --class > org.apache.hadoop.hbase.spark.IntegrationTestSparkBulkLoad > HBASE_HOME/lib/hbase-it-2.0.0-SNAPSHOT-tests.jar > -Dhbase.spark.bulkload.chainlength=50 -m slowDeterministic -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-17546) Incorrect syntax at HBase-Spark Module Examples
[ https://issues.apache.org/jira/browse/HBASE-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-17546: Fix Version/s: (was: 2.0.0-alpha-2) > Incorrect syntax at HBase-Spark Module Examples > --- > > Key: HBASE-17546 > URL: https://issues.apache.org/jira/browse/HBASE-17546 > Project: HBase > Issue Type: Bug > Components: spark >Affects Versions: 1.1.8 >Reporter: Chetan Khatri >Assignee: Chetan Khatri >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-17546.master.001.patch > > > Corrected : Syntax errors at HBase-Spark module > Description: > - Syntax errors has been correct at HBase-Spark module examples. > - Spark Transformation : somewhere show() and somewhere show only, corrected > to show(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18817) Pull hbase-spark module out of branch-2
[ https://issues.apache.org/jira/browse/HBASE-18817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176669#comment-16176669 ] Sean Busbey commented on HBASE-18817: - I bulk moved all JIRAs with fixVersion of 2.0.0* so that they'd have fix version 3.0.0. Also updated the backport jira to talk about branch-1 and branch-2. > Pull hbase-spark module out of branch-2 > --- > > Key: HBASE-18817 > URL: https://issues.apache.org/jira/browse/HBASE-18817 > Project: HBase > Issue Type: Task > Components: spark >Affects Versions: 2.0.0-alpha-2 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18817-branch-2.v0.patch > > > see DISCUSS here: > https://s.apache.org/UJAf > Sadly, feature is slipping out of branch-2. We can work out inclusion for > downstream once we have some inertia again. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17554) Figure 2.0.0 Hadoop Version Support; update refguide
[ https://issues.apache.org/jira/browse/HBASE-17554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176675#comment-16176675 ] Sean Busbey commented on HBASE-17554: - should we include a warning about how the table might be inaccurate for our hbase 2.0 alpha/beta releases? esp calling out that we'd like folks to report problems so we can have it be accurate for GA? > Figure 2.0.0 Hadoop Version Support; update refguide > > > Key: HBASE-17554 > URL: https://issues.apache.org/jira/browse/HBASE-17554 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Blocker > Fix For: 2.0.0 > > > Refguide has hbase-2.0.0 working with 2.6.1+ and 2.7.1+ but I just tried tip > of master against hadoop-2.7.3 and it fails with a netty version complaint > (same as up in HADOOP-13866 which is trying to update netty for hadoop3 and > 2.9?). This issue is about determining proper hadoop versions we work with > when hbase2 ships. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-13631) Migration from 0.94 to 2.0.0
[ https://issues.apache.org/jira/browse/HBASE-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176677#comment-16176677 ] Sean Busbey commented on HBASE-13631: - are we still interested in supporting 0.94 direct to 2.0.0? or is documenting "upgrade to version X.Y.Z first" sufficient? > Migration from 0.94 to 2.0.0 > > > Key: HBASE-13631 > URL: https://issues.apache.org/jira/browse/HBASE-13631 > Project: HBase > Issue Type: Sub-task > Components: migration >Reporter: Anoop Sam John >Priority: Blocker > Fix For: 2.0.0 > > > We have HFile V2 (minor version-2) only in 0.94 and 2.0 needs HFile V3 with > minor version 3 atleast. We can test and document clearly the path of upgrade > from 94.x to 2.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12081) Considering Java 9
[ https://issues.apache.org/jira/browse/HBASE-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176679#comment-16176679 ] Sean Busbey commented on HBASE-12081: - Maybe we should pull this back into one of the beta releases; it sounds like the changes it requires might have some perf impact on jdk8 folks? > Considering Java 9 > -- > > Key: HBASE-12081 > URL: https://issues.apache.org/jira/browse/HBASE-12081 > Project: HBase > Issue Type: Umbrella >Reporter: Andrew Purtell >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.5.0 > > > Java 9 will ship in 2016. This will be the first Java release that makes a > significant compatibility departure from earlier runtimes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-16338) update jackson to 2.y
[ https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-16338: Fix Version/s: (was: 2.0.0) 2.0.0-beta-2 > update jackson to 2.y > - > > Key: HBASE-16338 > URL: https://issues.apache.org/jira/browse/HBASE-16338 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Sean Busbey >Assignee: stack > Fix For: 2.0.0-beta-2 > > Attachments: 16338.txt > > > Our jackson dependency is from ~3 years ago. Update to the jackson 2.y line, > using 2.7.0+. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17285) Misconfiguration of JVM GC options in HADOOP_CLIENT_OPTS may break `bin/hbase`
[
https://issues.apache.org/jira/browse/HBASE-17285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176682#comment-16176682
]
Sean Busbey commented on HBASE-17285:
-
bump. still want this in 2.0 [~elserj], or happy to target master and see where
it lands on backport for earlier release lines?
> Misconfiguration of JVM GC options in HADOOP_CLIENT_OPTS may break `bin/hbase`
> --
>
> Key: HBASE-17285
> URL: https://issues.apache.org/jira/browse/HBASE-17285
> Project: HBase
> Issue Type: Bug
> Components: scripts
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17285.001.patch
>
>
> Had the great fun of digging through this one. Had a user reporting that
> hiveserver2 was no longer finding HBase jars on the classpath. This is
> supposed to happen via {{hbase mapredcp}}.
> It turned out that they had configured hive-env.sh to set
> {{HADOOP_CLIENT_OPTS="-XX:+PrintGCDetails"}} (among other things), which
> creates a big multi-line string instead of just a directory. Because of poor
> quoting in {{bin/hbase}}, this gives you a wonderfully intuitive error:
> {noformat}
> Error: Could not find or load main class Heap
> {noformat}
> That {{Heap}} is actually from the JVM GC details that it was told to print.
> While I don't expect this to be a common problem people run into, it's one
> that we can address with better quoting. e.g.
> {noformat}
> + exec
> /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java
> -Dproc_mapredcp '-XX:OnOutOfMemoryError=kill -9 %p' -XX:+UseConcMarkSweepGC
> -Dhbase.log.dir=/usr/local/lib/hbase//logs -Dhbase.log.file=hbase.log
> -Dhbase.home.dir=/usr/local/lib/hbase/ -Dhbase.id.str=
> -Dhbase.root.logger=INFO,console
> '-Djava.library.path='\''/usr/local/lib/hadoop//lib/native' Heap PSYoungGen
> total 76800K, used 7942K '[0x0007f550,' 0x0007faa8,
> '0x0008)' eden space 66048K, 12% used
> '[0x0007f550,0x0007f5cc19c0,0x0007f958)' from space
> 10752K, 0% used '[0x0007fa00,0x0007fa00,0x0007faa8)'
> to space 10752K, 0% used
> '[0x0007f958,0x0007f958,0x0007fa00)' ParOldGen total
> 174592K, used 0K '[0x0007e000,' 0x0007eaa8,
> '0x0007f550)' object space 174592K, 0% used
> '[0x0007e000,0x0007e000,0x0007eaa8)' PSPermGen total
> 21504K, used 2756K '[0x0007dae0,' 0x0007dc30,
> '0x0007e000)' object space 21504K, 12% used
> '[0x0007dae0,0x0007db0b11b8,0x0007dc30)'\'''
> -Dhbase.security.logger=INFO,NullAppender
> org.apache.hadoop.hbase.util.MapreduceDependencyClasspathTool
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18792) hbase-2 needs to defend against hbck operations
[ https://issues.apache.org/jira/browse/HBASE-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18792: Component/s: hbck > hbase-2 needs to defend against hbck operations > --- > > Key: HBASE-18792 > URL: https://issues.apache.org/jira/browse/HBASE-18792 > Project: HBase > Issue Type: Task > Components: hbck >Reporter: stack >Priority: Critical > Fix For: 2.0.0 > > > hbck needs updating to run against hbase2. Meantime, if an hbck from hbase1 > is run against hbck2, it may do damage. hbase2 should defend itself against > hbck1 ops. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17918) document serial replication
[
https://issues.apache.org/jira/browse/HBASE-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176685#comment-16176685
]
Sean Busbey commented on HBASE-17918:
-
still working on this [~yangzhe1991]?
> document serial replication
> ---
>
> Key: HBASE-17918
> URL: https://issues.apache.org/jira/browse/HBASE-17918
> Project: HBase
> Issue Type: Task
> Components: documentation, Replication
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Sean Busbey
>Assignee: Phil Yang
>Priority: Critical
> Fix For: 2.0.0
>
>
> It looks like HBASE-9465 addresses one of the major flaws in our existing
> replication (namely that order of delivery is not assured). All I see in the
> reference guide is a note on {{hbase.serial.replication.waitingMs}}. Instead
> we should cover this in the replication section, especially given that we
> call out the order of delivery limitation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-17918) document serial replication
[
https://issues.apache.org/jira/browse/HBASE-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-17918:
Component/s: documentation
> document serial replication
> ---
>
> Key: HBASE-17918
> URL: https://issues.apache.org/jira/browse/HBASE-17918
> Project: HBase
> Issue Type: Task
> Components: documentation, Replication
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Sean Busbey
>Assignee: Phil Yang
>Priority: Critical
> Fix For: 2.0.0
>
>
> It looks like HBASE-9465 addresses one of the major flaws in our existing
> replication (namely that order of delivery is not assured). All I see in the
> reference guide is a note on {{hbase.serial.replication.waitingMs}}. Instead
> we should cover this in the replication section, especially given that we
> call out the order of delivery limitation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-17285) Misconfiguration of JVM GC options in HADOOP_CLIENT_OPTS may break `bin/hbase`
[
https://issues.apache.org/jira/browse/HBASE-17285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176692#comment-16176692
]
Hadoop QA commented on HBASE-17285:
---
| (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 12s{color}
| {color:red} HBASE-17285 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-17285 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12842640/HBASE-17285.001.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/8746/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Misconfiguration of JVM GC options in HADOOP_CLIENT_OPTS may break `bin/hbase`
> --
>
> Key: HBASE-17285
> URL: https://issues.apache.org/jira/browse/HBASE-17285
> Project: HBase
> Issue Type: Bug
> Components: scripts
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17285.001.patch
>
>
> Had the great fun of digging through this one. Had a user reporting that
> hiveserver2 was no longer finding HBase jars on the classpath. This is
> supposed to happen via {{hbase mapredcp}}.
> It turned out that they had configured hive-env.sh to set
> {{HADOOP_CLIENT_OPTS="-XX:+PrintGCDetails"}} (among other things), which
> creates a big multi-line string instead of just a directory. Because of poor
> quoting in {{bin/hbase}}, this gives you a wonderfully intuitive error:
> {noformat}
> Error: Could not find or load main class Heap
> {noformat}
> That {{Heap}} is actually from the JVM GC details that it was told to print.
> While I don't expect this to be a common problem people run into, it's one
> that we can address with better quoting. e.g.
> {noformat}
> + exec
> /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java
> -Dproc_mapredcp '-XX:OnOutOfMemoryError=kill -9 %p' -XX:+UseConcMarkSweepGC
> -Dhbase.log.dir=/usr/local/lib/hbase//logs -Dhbase.log.file=hbase.log
> -Dhbase.home.dir=/usr/local/lib/hbase/ -Dhbase.id.str=
> -Dhbase.root.logger=INFO,console
> '-Djava.library.path='\''/usr/local/lib/hadoop//lib/native' Heap PSYoungGen
> total 76800K, used 7942K '[0x0007f550,' 0x0007faa8,
> '0x0008)' eden space 66048K, 12% used
> '[0x0007f550,0x0007f5cc19c0,0x0007f958)' from space
> 10752K, 0% used '[0x0007fa00,0x0007fa00,0x0007faa8)'
> to space 10752K, 0% used
> '[0x0007f958,0x0007f958,0x0007fa00)' ParOldGen total
> 174592K, used 0K '[0x0007e000,' 0x0007eaa8,
> '0x0007f550)' object space 174592K, 0% used
> '[0x0007e000,0x0007e000,0x0007eaa8)' PSPermGen total
> 21504K, used 2756K '[0x0007dae0,' 0x0007dc30,
> '0x0007e000)' object space 21504K, 12% used
> '[0x0007dae0,0x0007db0b11b8,0x0007dc30)'\'''
> -Dhbase.security.logger=INFO,NullAppender
> org.apache.hadoop.hbase.util.MapreduceDependencyClasspathTool
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18591) Upgrade thrift from 0.9.3 to 0.10.0
[ https://issues.apache.org/jira/browse/HBASE-18591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176691#comment-16176691 ] Sean Busbey commented on HBASE-18591: - Folks already have enough challenges ahead for getting from HBase 1 to HBase 2. Let's leave our Thrift based proxy as-is as a backdoor for older clients just in case. Can always add a new module later that does thrift 0.10 based comms. > Upgrade thrift from 0.9.3 to 0.10.0 > --- > > Key: HBASE-18591 > URL: https://issues.apache.org/jira/browse/HBASE-18591 > Project: HBase > Issue Type: Bug > Components: Thrift >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: 18591.txt > > > Maybe we don't want to do this for 2.0.0. Maybe we want to let it up to the > implementor. Going to 0.10.0 will probably break any 0.9.3 clients. I could > try it I suppose but if past experience is anything to go by...it'll break > (There is this note that it is broke up on happybase > https://github.com/wbolster/happybase/issues/154). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-7218) Rename Snapshot
[ https://issues.apache.org/jira/browse/HBASE-7218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reassigned HBASE-7218: -- Assignee: (was: Matteo Bertozzi) Fix Version/s: (was: 2.0.0) 3.0.0 > Rename Snapshot > --- > > Key: HBASE-7218 > URL: https://issues.apache.org/jira/browse/HBASE-7218 > Project: HBase > Issue Type: New Feature > Components: snapshots >Reporter: Matteo Bertozzi >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-7218-v0.patch, HBASE-7218-v1.patch > > > Add the ability to rename a snapshot. > HBaseAdmin.renameSnapshot(oldName, newName) > shell: snapshot_rename 'oldName', 'newName' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18844) Release hbase-2.0.0-alpha-4; Theme "Coprocessor API Cleanup"
[ https://issues.apache.org/jira/browse/HBASE-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reassigned HBASE-18844: --- Assignee: stack > Release hbase-2.0.0-alpha-4; Theme "Coprocessor API Cleanup" > > > Key: HBASE-18844 > URL: https://issues.apache.org/jira/browse/HBASE-18844 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18865) Ensure system tables can have their WALs split prior to user tables
Sean Busbey created HBASE-18865:
---
Summary: Ensure system tables can have their WALs split prior to
user tables
Key: HBASE-18865
URL: https://issues.apache.org/jira/browse/HBASE-18865
Project: HBase
Issue Type: New Feature
Components: wal
Affects Versions: 2.0.0
Reporter: Sean Busbey
Priority: Critical
Fix For: 2.0.0
>From a comment on HBASE-14190 and repeated on HBASE-18109 from [~yangzhe1991]:
{quote}
If I am not wrong, for system tables expect meta we still share logs with user
regions, so even if we have some logic to assign system tables first, we still
need wait log splitting done and we can not guarantee logs of system tables are
split first. So there may be a blocking task that we should make multi-log
feature having priority and write entries of system table in the highest
priority logs. Thanks.
{quote}
This is an umbrella for working out our long term plan around how we handle WAL
prioritization and recovery.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18591) Upgrade thrift from 0.9.3 to 0.10.0
[ https://issues.apache.org/jira/browse/HBASE-18591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-18591: -- Fix Version/s: (was: 2.0.0) > Upgrade thrift from 0.9.3 to 0.10.0 > --- > > Key: HBASE-18591 > URL: https://issues.apache.org/jira/browse/HBASE-18591 > Project: HBase > Issue Type: Bug > Components: Thrift >Reporter: stack >Assignee: stack > Attachments: 18591.txt > > > Maybe we don't want to do this for 2.0.0. Maybe we want to let it up to the > implementor. Going to 0.10.0 will probably break any 0.9.3 clients. I could > try it I suppose but if past experience is anything to go by...it'll break > (There is this note that it is broke up on happybase > https://github.com/wbolster/happybase/issues/154). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18591) Upgrade thrift from 0.9.3 to 0.10.0
[ https://issues.apache.org/jira/browse/HBASE-18591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176731#comment-16176731 ] stack commented on HBASE-18591: --- Unscheduling from 2.0.0. Shout if you have a different opinion. > Upgrade thrift from 0.9.3 to 0.10.0 > --- > > Key: HBASE-18591 > URL: https://issues.apache.org/jira/browse/HBASE-18591 > Project: HBase > Issue Type: Bug > Components: Thrift >Reporter: stack >Assignee: stack > Attachments: 18591.txt > > > Maybe we don't want to do this for 2.0.0. Maybe we want to let it up to the > implementor. Going to 0.10.0 will probably break any 0.9.3 clients. I could > try it I suppose but if past experience is anything to go by...it'll break > (There is this note that it is broke up on happybase > https://github.com/wbolster/happybase/issues/154). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18645) Loads of tests timing out....
[ https://issues.apache.org/jira/browse/HBASE-18645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176741#comment-16176741 ] Andrew Purtell commented on HBASE-18645: bq. If we go the revert approach, please do it in a new branch that we can remove when we're done. Ah yes, great, if we do it this way I have no concerns. > Loads of tests timing out > - > > Key: HBASE-18645 > URL: https://issues.apache.org/jira/browse/HBASE-18645 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Critical > Attachments: HBASE-18645.master.001.patch, > HBASE-18645.master.001.patch > > > Whats up? Why are tests mostly timing out? When did it start? I can't seem to > make it happen locally so tough doing a bisect. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18645) Loads of tests timing out....
[ https://issues.apache.org/jira/browse/HBASE-18645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176749#comment-16176749 ] Andrew Purtell commented on HBASE-18645: FWIW I'm going to start testing with underpowered AWS instance types next week to more closely match what goes on with ASF build resources. Might run a continuous dd process in the background too. Don't block on me, though. If I find issues I'll open jirs for test fixes we can work on independent of failure isolation by block revert. > Loads of tests timing out > - > > Key: HBASE-18645 > URL: https://issues.apache.org/jira/browse/HBASE-18645 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Critical > Attachments: HBASE-18645.master.001.patch, > HBASE-18645.master.001.patch > > > Whats up? Why are tests mostly timing out? When did it start? I can't seem to > make it happen locally so tough doing a bisect. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176774#comment-16176774
]
Chia-Ping Tsai commented on HBASE-18847:
Excluding TestExportSnapshot, all tests pass locally. The TestExportSnapshot
fails without patch. So +1
> remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176774#comment-16176774
]
Chia-Ping Tsai edited comment on HBASE-18847 at 9/22/17 5:35 PM:
-
Excluding TestExportSnapshot, all tests pass locally. The TestExportSnapshot
fails without patch. So +1
(maybe TestExportSnapshot is related to HBASE-18645)
was (Author: chia7712):
Excluding TestExportSnapshot, all tests pass locally. The TestExportSnapshot
fails without patch. So +1
> remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176789#comment-16176789
]
Sean Busbey commented on HBASE-18847:
-
awesome! feel free to push at your convenience.
> remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18847) remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176794#comment-16176794
]
Chia-Ping Tsai commented on HBASE-18847:
Will commit it later.
> remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[
https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176797#comment-16176797
]
Ted Yu commented on HBASE-18843:
Patch v2 doesn't compile:
{code}
[ERROR]
/hbase/hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/util/FixedRelativePathCopyListing.java:[30,46]
package org.apache.hadoop.hbase.classification does not exist
[ERROR]
/hbase/hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/util/FixedRelativePathCopyListing.java:[54,19]
package InterfaceAudience does not exist
{code}
> Add DistCp support to incremental backup with bulk loading
> --
>
> Key: HBASE-18843
> URL: https://issues.apache.org/jira/browse/HBASE-18843
> Project: HBase
> Issue Type: Improvement
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch
>
>
> Currently, we copy bulk loaded files to backup one-by-one on a client side
> (where backup create runs). This has to be replaced with DistCp copying.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[ https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18796: --- Resolution: Fixed Status: Resolved (was: Patch Available) Tests check out. Pushed addendum to branch-1.4 and up > Admin#isTableAvailable returns incorrect result before daughter regions are > opened > -- > > Key: HBASE-18796 > URL: https://issues.apache.org/jira/browse/HBASE-18796 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0 > > Attachments: HBASE-18796-addendum.branch-1.patch, > HBASE-18796-addendum.master.patch, HBASE-18796.branch-1.001.patch, > HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.002.patch, > HBASE-18796.branch-1.003.patch, HBASE-18796.master.001.patch > > > Admin#isTableAvailable checks if it can getServerName for the meta entries it > reads. During the time of split server location are added to the meta entries > in MetaTableAccessor#splitRegion although the description of the method says > "Does not add the location information to the daughter regions since they are > not open yet.". At this point during the split daughter regions are not > actually open, so we can get to a state where parent is offline, daughters > are not yet open but isTableAvailable returns true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18796) Admin#isTableAvailable returns incorrect result before daughter regions are opened
[ https://issues.apache.org/jira/browse/HBASE-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176792#comment-16176792 ] Andrew Purtell commented on HBASE-18796: I committed this earlier to branch-1.3 also, but the branch-1 addendum doesn't apply there, so I reverted the original commit. If we want this change on branch-1.3 also please provide a new patch for branch-1.3. > Admin#isTableAvailable returns incorrect result before daughter regions are > opened > -- > > Key: HBASE-18796 > URL: https://issues.apache.org/jira/browse/HBASE-18796 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0 > > Attachments: HBASE-18796-addendum.branch-1.patch, > HBASE-18796-addendum.master.patch, HBASE-18796.branch-1.001.patch, > HBASE-18796.branch-1.001.patch, HBASE-18796.branch-1.002.patch, > HBASE-18796.branch-1.003.patch, HBASE-18796.master.001.patch > > > Admin#isTableAvailable checks if it can getServerName for the meta entries it > reads. During the time of split server location are added to the meta entries > in MetaTableAccessor#splitRegion although the description of the method says > "Does not add the location information to the daughter regions since they are > not open yet.". At this point during the split daughter regions are not > actually open, so we can get to a state where parent is offline, daughters > are not yet open but isTableAvailable returns true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18847) Remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18847:
---
Summary: Remove unneeded synchronized block from hfilev2 warning in
branch-1.2 (was: remove unneeded synchronized block from hfilev2 warning in
branch-1.2)
> Remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18847) Remove unneeded synchronized block from hfilev2 warning in branch-1.2
[
https://issues.apache.org/jira/browse/HBASE-18847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18847:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Push to branch-1.2. Thanks for the patch. [~richhowarth]
> Remove unneeded synchronized block from hfilev2 warning in branch-1.2
> -
>
> Key: HBASE-18847
> URL: https://issues.apache.org/jira/browse/HBASE-18847
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
>Reporter: Rich Howarth
>Assignee: Rich Howarth
>Priority: Critical
> Fix For: 1.2.7
>
> Attachments: HBASE-18847-branch-1.2-00.patch
>
>
> The below code block starts at line 277 of HFileWriterV2.java. Class-level
> synchronization in a heavily used code path has a demonstrably significant
> negative effect on performance. I tested forcing a major compaction with 18
> compaction threads per node; removing the synchronization resulted in an
> order of magnitude performance increase, with the bottleneck then being at
> the disks (where I want it to be).
> {code:java}
> synchronized (HFileWriterV2.class) {
> if (WARN_CELL_WITH_TAGS && getFileContext().isIncludesTags()) {
> LOG.warn("A minimum HFile version of " +
> HFile.MIN_FORMAT_VERSION_WITH_TAGS
> + " is required to support cell attributes/tags. Consider setting "
> + HFile.FORMAT_VERSION_KEY + " accordingly.");
> WARN_CELL_WITH_TAGS = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
