[jira] [Commented] (HBASE-18104) [AMv2] Enable aggregation of RPCs (assigns/unassigns, etc.)
[
https://issues.apache.org/jira/browse/HBASE-18104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052703#comment-16052703
]
Hadoop QA commented on HBASE-18104:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 12s
{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
19s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {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} hadoopcheck {color} | {color:green}
28m 8s {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-alpha3. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 0s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 107m 12s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
19s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 148m 14s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12873359/HBASE-18104.master.001.patch
|
| JIRA Issue | HBASE-18104 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 89ca7596737c 3.13.0-107-generic #154-Ubuntu SMP Tue Dec 20
09:57:27 UTC 2016 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 / b02d3d9 |
| Default Java | 1.8.0_131 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7215/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7215/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> [AMv2] Enable aggregation of RPCs (assigns/unassigns, etc.)
> ---
>
> Key: HBASE-18104
> URL: https://issues.apache.org/jira/browse/HBASE-18104
> Project: HBase
> Issue Type: Sub-task
> Components: Region Assignment
>Affects
[jira] [Commented] (HBASE-18144) Forward-port the old exclusive row lock; there are scenarios where it performs better
[ https://issues.apache.org/jira/browse/HBASE-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052697#comment-16052697 ] stack commented on HBASE-18144: --- [~anoop.hbase] The old code is pretty hard to fathom. The waitForLock operation in particular was cryptic. When set, if the current thread is NOT the thread that owns the lock, then return the null lock. The null lock signals the end of a batch. The batch needs to be processed before we can give this new thread the row lock. The old exclusive lock was reentrant; if the same thread passing us Mutations, then we'd only get the lock the first time through. All subsequent mutations would operate under the umbrella of the exclusive lock (until a new thread came in... then we'd 'flush'). [~allan163] The temporary deadlocking you describe seems legit (thanks!). I think sorting helps but does not eliminate. Let me play around some here. I think I can get your suggestion deployed on the problematic cluster... Let me see. > Forward-port the old exclusive row lock; there are scenarios where it > performs better > - > > Key: HBASE-18144 > URL: https://issues.apache.org/jira/browse/HBASE-18144 > Project: HBase > Issue Type: Bug > Components: Increment >Affects Versions: 1.2.5 >Reporter: stack >Assignee: stack > Fix For: 2.0.0, 1.3.2, 1.2.7 > > Attachments: DisorderedBatchAndIncrementUT.patch, > HBASE-18144.master.001.patch > > > Description to follow. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18170) Refactor ReplicationSourceWALReaderThread
[ https://issues.apache.org/jira/browse/HBASE-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052691#comment-16052691 ] stack commented on HBASE-18170: --- I know you are following someone else's pattern which is good but ReplicationSourceWALReaderThread is poor name for class no need of the Thread suffix I'd say. but can change it and ReplicationSourceWALReaderThread in a new issue. 85 Threads.setDaemonThreadRunning(walReader, threadName 86 + ".replicationSource.replicationWALReaderThread." + walGroupId + "," + peerClusterZnode, 87getUncaughtExceptionHandler()); 88 return walReader; Could just return Threads.setDaemon The method returns the passed in 'thread'. Ditto for later in the patch. The above are nits. +1 > Refactor ReplicationSourceWALReaderThread > - > > Key: HBASE-18170 > URL: https://issues.apache.org/jira/browse/HBASE-18170 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-18170.master.001.patch, > HBASE-18170.master.001.patch, HBASE-18170.master.002.patch, > HBASE-18170.master.002.patch, HBASE-18170.master.003.patch, > HBASE-18170.master.004.patch > > > HBASE-18130 add some get* method to ReplicationSource. So > ReplicationSourceWALReaderThread doesn't need so many parameter to > initialize. And the WALEntryFilter only used by > ReplicationSourceWALReaderThread, so we don't need to new it for every > ReplicationSourceWALReaderThread. Meanwhile, we can separate a new > RecoveredReplicationSourceWALReaderThread for recovered replication source. > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18228) HBCK improvements
[ https://issues.apache.org/jira/browse/HBASE-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052690#comment-16052690 ] Lars Hofhansl commented on HBASE-18228: --- bq. 2.x will likely rewrite hbck for its particular problems. Hmm... 2.s is a monster as is. I do not think we should do another rewrite of a larger chunk of until 3.x (or whatever the next one is called) > HBCK improvements > - > > Key: HBASE-18228 > URL: https://issues.apache.org/jira/browse/HBASE-18228 > Project: HBase > Issue Type: Improvement > Components: hbck >Reporter: Lars Hofhansl >Priority: Critical > Fix For: 1.4.0 > > > We just had a prod issue and running HBCK the way we did actually causes more > problems. > In part HBCK did stuff we did not expect, in part we had little visibility > into what HBCK was doing, and in part the logging was confusing. > I'm proposing 2 improvements: > 1. A dry-run mode. Run, and just list what would have been done. > 2. An interactive mode. Run, and for each action request Y/N user input. So > that a user can opt-out of stuff. > [~jmhsieh], FYI -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18144) Forward-port the old exclusive row lock; there are scenarios where it performs better
[ https://issues.apache.org/jira/browse/HBASE-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052687#comment-16052687 ] Anoop Sam John commented on HBASE-18144: Am noticing this change now only. Am checking master code. Ya previously the boolean param was deciding whether we should wait for the lock or not. That was true for the 1st row in the batch and false otherwise. (As Allan explained above).. We do the mutations in mini batches. Now seems we dont have this boolean param based decision at all.. Any idea which issue changed this way? [~carp84]. Thanks for the nice explanation Allan. > Forward-port the old exclusive row lock; there are scenarios where it > performs better > - > > Key: HBASE-18144 > URL: https://issues.apache.org/jira/browse/HBASE-18144 > Project: HBase > Issue Type: Bug > Components: Increment >Affects Versions: 1.2.5 >Reporter: stack >Assignee: stack > Fix For: 2.0.0, 1.3.2, 1.2.7 > > Attachments: DisorderedBatchAndIncrementUT.patch, > HBASE-18144.master.001.patch > > > Description to follow. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (HBASE-18004) getRegionLocations needs to be called once in ScannerCallableWithReplicas#call()
[ https://issues.apache.org/jira/browse/HBASE-18004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reopened HBASE-18004: --- Reopen for branch-1 patch. > getRegionLocations needs to be called once in > ScannerCallableWithReplicas#call() > - > > Key: HBASE-18004 > URL: https://issues.apache.org/jira/browse/HBASE-18004 > Project: HBase > Issue Type: Improvement > Components: Client >Affects Versions: 2.0.0 >Reporter: huaxiang sun >Assignee: huaxiang sun >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-18004.branch-1.001.patch, > HBASE-18004-master-001.patch, HBASE-18004-master-002.patch > > > Look at this line, > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/ScannerCallableWithReplicas.java#L145 > It calls getRegionLocations() to get the primary region's locations. It's > usage is to figure out table's region replications. Since table's region > replication wont be changed until the table is disabled. It is safe to cache > this region replication. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052683#comment-16052683 ] stack commented on HBASE-18229: --- Review up on rb. Patch is great. I missed this comment: bq. When input splitRow is null, I add a new rpc call (GetBestSplitPointResponse) instead of add to the GetRegionInfoResponse protobuf Is it expensive getting split point (isn't it just look up into in-memory indices?) I was thinking jsut add it to GetRegionInfoResponse if cheap and save an rpc (ideal distributed cluster has 0 RPCs -- nothing can go wrong then!!) > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang > Attachments: HBase-18229-master-v1.patch > > > See HBASE-18105 for related information, this jira will change the logic of > Path 1 in splitProcedure, the execution path will be: > *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> > MasterRpcServices.splitRegion -> HMaster.splitRegion-> > AssignmentManager.submitProcedure* > Master Will no longer as Rs and then Rs turn around to ask master to do the > split operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (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:comment-tabpanel=16052681#comment-16052681
]
Hadoop QA commented on HBASE-18176:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 14s
{color} | {color:blue} Docker mode activated. {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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 29s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
48s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 30s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 34s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 13s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 8s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m 8s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
58s {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} xml {color} | {color:green} 0m 4s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
31m 5s {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-alpha3. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m 36s
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 13s
{color} | {color:green} hbase-assembly in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 127m 56s
{color} | {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
59s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 192m 24s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestMasterProcedureWalLease |
| Timed out junit tests |
org.apache.hadoop.hbase.coprocessor.TestCoprocessorMetrics |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12873353/HBASE-18176.v2.patch |
| JIRA Issue | HBASE-18176 |
| Optional Tests | asflicense javac javadoc unit xml compile |
| uname | Linux a40cdf0caeba 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31
14:13:22 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 / cd478d1 |
| Default Java | 1.8.0_131 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/7213/artifact/patchprocess/patch-unit-root.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/7213/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7213/testReport/ |
| modules | C: hbase-spark hbase-assembly . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7213/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
[jira] [Commented] (HBASE-18229) create new Async Split API to embrace AM v2
[
https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052673#comment-16052673
]
Hadoop QA commented on HBASE-18229:
---
| (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:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 24s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
47s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 2s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 21m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
57s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 5m 28s
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 38s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 20s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 21m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
4s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 5 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
60m 19s {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-alpha3. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 2m
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 20m
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 55s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 58s
{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 5m 0s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 140m 2s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 7m
29s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 317m 50s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestRegionReplicaFailover |
| | hadoop.hbase.regionserver.TestPerColumnFamilyFlush |
| | hadoop.hbase.coprocessor.TestRegionObserverInterface |
| | hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort |
| Timed out junit tests |
org.apache.hadoop.hbase.replication.regionserver.TestRegionReplicaReplicationEndpoint
|
| | org.apache.hadoop.hbase.coprocessor.TestCoprocessorMetrics |
| | org.apache.hadoop.hbase.replication.regionserver.TestWALEntryStream |
| |
[jira] [Updated] (HBASE-18170) Refactor ReplicationSourceWALReaderThread
[ https://issues.apache.org/jira/browse/HBASE-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-18170: --- Attachment: HBASE-18170.master.004.patch > Refactor ReplicationSourceWALReaderThread > - > > Key: HBASE-18170 > URL: https://issues.apache.org/jira/browse/HBASE-18170 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-18170.master.001.patch, > HBASE-18170.master.001.patch, HBASE-18170.master.002.patch, > HBASE-18170.master.002.patch, HBASE-18170.master.003.patch, > HBASE-18170.master.004.patch > > > HBASE-18130 add some get* method to ReplicationSource. So > ReplicationSourceWALReaderThread doesn't need so many parameter to > initialize. And the WALEntryFilter only used by > ReplicationSourceWALReaderThread, so we don't need to new it for every > ReplicationSourceWALReaderThread. Meanwhile, we can separate a new > RecoveredReplicationSourceWALReaderThread for recovered replication source. > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18104) [AMv2] Enable aggregation of RPCs (assigns/unassigns, etc.)
[ https://issues.apache.org/jira/browse/HBASE-18104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052668#comment-16052668 ] stack commented on HBASE-18104: --- Thanks [~uagashe] Lets see how retry does this time. > [AMv2] Enable aggregation of RPCs (assigns/unassigns, etc.) > --- > > Key: HBASE-18104 > URL: https://issues.apache.org/jira/browse/HBASE-18104 > Project: HBase > Issue Type: Sub-task > Components: Region Assignment >Affects Versions: 2.0.0 >Reporter: stack >Assignee: Umesh Agashe > Fix For: 2.0.0 > > Attachments: HBASE-18104.master.001.patch, > HBASE-18104.master.001.patch, HBASE-18104.master.001.patch > > > Machinery is in place to coalesce AMv2 RPCs (Assigns, Unassigns). It needs > enabling and verification. From '6.3 We don’t do the aggregating of Assigns' > of > https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.uuwvci2r2tz4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052667#comment-16052667
]
Umesh Agashe commented on HBASE-18227:
--
Thanks for reviewing and committing patch, [~stack]!
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
>
> Key: HBASE-18227
> URL: https://issues.apache.org/jira/browse/HBASE-18227
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0
>
> Attachments: HBASE-18227.master.001.patch
>
>
> When ExecuteProceduresRemoteCall in RemoteProcedureDispatcher is enabled the
> test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
> fails as it uses not supported call admin.closeRegion() to close a region.
> Disabling table later throws exception as one of the region is not online
> (already closed).
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> 2017-06-16 11:25:02,177 WARN [RSProcedureDispatcher-pool4-t6]
> procedure.RSProcedureDispatcher$AbstractRSRemoteCall(200): the request should
> be tried elsewhere instead; server=172.21.2.192,53652,1497637493318 try=0
> org.apache.hadoop.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:93)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:83)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:370)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:347)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.sendRequest(RSProcedureDispatcher.java:295)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:265)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:246)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.NotServingRegionException):
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is
[jira] [Commented] (HBASE-18102) [SHELL] Purge commands that allow by-pass of Master; e.g. close of a region sent to regionserver explicitly
[ https://issues.apache.org/jira/browse/HBASE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052665#comment-16052665 ] stack commented on HBASE-18102: --- See over in HBASE-18227. [~uagashe] found that the Admin has #closeRegion and calling it does damage to your cluster now AMv2 is in because it skirts the master to ask the regionserver to close the region. Instead we should be calling unassign. Filed HBASE-18231 to do the cleanup. This issue then depends on HBASE-18231. It needs to happen before this. Shell then needs to work w/ HBASE-18231 by providing alternatives or making the thrown exception go down easier. > [SHELL] Purge commands that allow by-pass of Master; e.g. close of a region > sent to regionserver explicitly > --- > > Key: HBASE-18102 > URL: https://issues.apache.org/jira/browse/HBASE-18102 > Project: HBase > Issue Type: Sub-task > Components: Operability, shell >Reporter: stack > Fix For: 2.0.0 > > > In AMv2, if a RS is not aligned with Master notions of how the world is, then > the Master will kill the deviant RS (TODO: is forcing compliance via less > radical means -- but that is how it is currently). > The shell currently allows by-passing the Master to make cluster > modifications such as our being able to send a close directly to a > RegionServer for it to execute locally. This facility was used in the past to > do fix-up when Master lost account of Region locations. In the new regime, > such mis-accounting should no longer happen and, should a user mistakenly do > an explicit close against a RS, the consequences will be more than the user > bargained for; the Master will shut down the RS as soon as it reports close > of a Region the master thinks should be open (No independence allowed!). > This issue is to review shell Region and Table manipulation commands to purge > those that by-pass Master or at least to add big warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052666#comment-16052666
]
stack commented on HBASE-18227:
---
Filed HBASE-18231 to do the Admin#closeRegion cleanup.
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
>
> Key: HBASE-18227
> URL: https://issues.apache.org/jira/browse/HBASE-18227
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0
>
> Attachments: HBASE-18227.master.001.patch
>
>
> When ExecuteProceduresRemoteCall in RemoteProcedureDispatcher is enabled the
> test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
> fails as it uses not supported call admin.closeRegion() to close a region.
> Disabling table later throws exception as one of the region is not online
> (already closed).
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> 2017-06-16 11:25:02,177 WARN [RSProcedureDispatcher-pool4-t6]
> procedure.RSProcedureDispatcher$AbstractRSRemoteCall(200): the request should
> be tried elsewhere instead; server=172.21.2.192,53652,1497637493318 try=0
> org.apache.hadoop.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:93)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:83)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:370)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:347)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.sendRequest(RSProcedureDispatcher.java:295)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:265)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:246)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.NotServingRegionException):
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online,
[jira] [Updated] (HBASE-17752) Update reporting RPCs/Shell commands to break out space utilization by snapshot
[
https://issues.apache.org/jira/browse/HBASE-17752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-17752:
---
Attachment: HBASE-17752.004.patch
.004 Addresses Mike and Ted's comments.
> Update reporting RPCs/Shell commands to break out space utilization by
> snapshot
> ---
>
> Key: HBASE-17752
> URL: https://issues.apache.org/jira/browse/HBASE-17752
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: Josh Elser
> Attachments: HBASE-17752.001.patch, HBASE-17752.002.patch,
> HBASE-17752.003.patch, HBASE-17752.004.patch
>
>
> For adminstrators running HBase with space quotas, it is useful to provide a
> breakdown of the utilization of a table. For example, it may be non-intuitive
> that a table's utilization is primarily made up of snapshots. We should
> provide a new command or modify existing commands such that an admin can see
> the utilization for a table/ns:
> e.g.
> {noformat}
> table1: 17GB
> resident: 10GB
> snapshot_a: 5GB
> snapshot_b: 2GB
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18231) Deprecate and throw unsupported operation when Admin#closeRegion is called.
stack created HBASE-18231: - Summary: Deprecate and throw unsupported operation when Admin#closeRegion is called. Key: HBASE-18231 URL: https://issues.apache.org/jira/browse/HBASE-18231 Project: HBase Issue Type: Sub-task Components: Admin Affects Versions: 2.0.0 Reporter: stack Priority: Critical [~uagashe] tripped over this today. Admin#closeRegion which we used to use in branch-1 will cause damage in AMv2 cluster. Instead you need to call unassign -- i.e. all cluster ops must go via the Master; no more going direct to RegionServer closing regions behind the Master's back. Review all Admin ops to see what else skirts Master and deprecate and throw unsupported if called. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18104) [AMv2] Enable aggregation of RPCs (assigns/unassigns, etc.)
[ https://issues.apache.org/jira/browse/HBASE-18104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe updated HBASE-18104: - Attachment: HBASE-18104.master.001.patch retry same patch after fix for HBASE-18227. > [AMv2] Enable aggregation of RPCs (assigns/unassigns, etc.) > --- > > Key: HBASE-18104 > URL: https://issues.apache.org/jira/browse/HBASE-18104 > Project: HBase > Issue Type: Sub-task > Components: Region Assignment >Affects Versions: 2.0.0 >Reporter: stack >Assignee: Umesh Agashe > Fix For: 2.0.0 > > Attachments: HBASE-18104.master.001.patch, > HBASE-18104.master.001.patch, HBASE-18104.master.001.patch > > > Machinery is in place to coalesce AMv2 RPCs (Assigns, Unassigns). It needs > enabling and verification. From '6.3 We don’t do the aggregating of Assigns' > of > https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.uuwvci2r2tz4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-18227:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
Status: Resolved (was: Patch Available)
Agree [~uagashe]
Pushed to master and branch-2. Thanks for the patch sir.
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
>
> Key: HBASE-18227
> URL: https://issues.apache.org/jira/browse/HBASE-18227
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0
>
> Attachments: HBASE-18227.master.001.patch
>
>
> When ExecuteProceduresRemoteCall in RemoteProcedureDispatcher is enabled the
> test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
> fails as it uses not supported call admin.closeRegion() to close a region.
> Disabling table later throws exception as one of the region is not online
> (already closed).
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> 2017-06-16 11:25:02,177 WARN [RSProcedureDispatcher-pool4-t6]
> procedure.RSProcedureDispatcher$AbstractRSRemoteCall(200): the request should
> be tried elsewhere instead; server=172.21.2.192,53652,1497637493318 try=0
> org.apache.hadoop.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:93)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:83)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:370)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:347)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.sendRequest(RSProcedureDispatcher.java:295)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:265)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:246)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.NotServingRegionException):
>
[jira] [Commented] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052655#comment-16052655
]
Umesh Agashe commented on HBASE-18227:
--
hbase.master.procedure.TestMasterProcedureWalLease is in flaky list and changes
are only in
hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
which is unlikely to cause this failure.
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
>
> Key: HBASE-18227
> URL: https://issues.apache.org/jira/browse/HBASE-18227
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Attachments: HBASE-18227.master.001.patch
>
>
> When ExecuteProceduresRemoteCall in RemoteProcedureDispatcher is enabled the
> test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
> fails as it uses not supported call admin.closeRegion() to close a region.
> Disabling table later throws exception as one of the region is not online
> (already closed).
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> 2017-06-16 11:25:02,177 WARN [RSProcedureDispatcher-pool4-t6]
> procedure.RSProcedureDispatcher$AbstractRSRemoteCall(200): the request should
> be tried elsewhere instead; server=172.21.2.192,53652,1497637493318 try=0
> org.apache.hadoop.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:93)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:83)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:370)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:347)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.sendRequest(RSProcedureDispatcher.java:295)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:265)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:246)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
>
[jira] [Resolved] (HBASE-18100) TestBlockEvictionFromClient#testBlockRefCountAfterSplits is flaky in master branch
[
https://issues.apache.org/jira/browse/HBASE-18100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu resolved HBASE-18100.
Resolution: Cannot Reproduce
Not appearing on flaky dash board any more.
> TestBlockEvictionFromClient#testBlockRefCountAfterSplits is flaky in master
> branch
> --
>
> Key: HBASE-18100
> URL: https://issues.apache.org/jira/browse/HBASE-18100
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Priority: Minor
> Attachments: testBlockEvictionFromClient-05-24.out
>
>
> https://builds.apache.org/job/HBASE-Flaky-Tests/lastCompletedBuild/testReport/org.apache.hadoop.hbase.client/TestBlockEvictionFromClient/testBlockRefCountAfterSplits/
> {code}
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.iterateBlockCache(TestBlockEvictionFromClient.java:1215)
> at
> org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.testBlockRefCountAfterSplits(TestBlockEvictionFromClient.java:607)
> {code}
> The test failed on May 16th as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (HBASE-18216) [AMv2] Workaround for HBASE-18152, corrupt procedure WAL
[ https://issues.apache.org/jira/browse/HBASE-18216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reopened HBASE-18216: --- Reopen so can apply to branch-1 which can have same issue; see HBASE-18152. > [AMv2] Workaround for HBASE-18152, corrupt procedure WAL > > > Key: HBASE-18216 > URL: https://issues.apache.org/jira/browse/HBASE-18216 > Project: HBase > Issue Type: Bug > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-18216.branch-1.001.patch > > > Let me commit workaround for the issue up in HBASE-18152, corruption in the > master wal procedure files. Testing on cluster shows it helps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18170) Refactor ReplicationSourceWALReaderThread
[
https://issues.apache.org/jira/browse/HBASE-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052649#comment-16052649
]
Ted Yu commented on HBASE-18170:
{code}
++ ".replicationSource.replicationWALReaderThread." + walGroupId + ","
+ peerClusterZnode,
{code}
Can the thread name be shorter ? e.g. replicationWALReaderThread -> wal-reader
{code}
+public class RecoveredReplicationSourceWALReaderThread extends
ReplicationSourceWALReaderThread {
{code}
Add javadoc for the class.
For ReplicationSourceInterface, is the import of WALEntryFilter used ?
> Refactor ReplicationSourceWALReaderThread
> -
>
> Key: HBASE-18170
> URL: https://issues.apache.org/jira/browse/HBASE-18170
> Project: HBase
> Issue Type: Improvement
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Attachments: HBASE-18170.master.001.patch,
> HBASE-18170.master.001.patch, HBASE-18170.master.002.patch,
> HBASE-18170.master.002.patch, HBASE-18170.master.003.patch
>
>
> HBASE-18130 add some get* method to ReplicationSource. So
> ReplicationSourceWALReaderThread doesn't need so many parameter to
> initialize. And the WALEntryFilter only used by
> ReplicationSourceWALReaderThread, so we don't need to new it for every
> ReplicationSourceWALReaderThread. Meanwhile, we can separate a new
> RecoveredReplicationSourceWALReaderThread for recovered replication source.
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-16242) Upgrade Avro
[
https://issues.apache.org/jira/browse/HBASE-16242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052647#comment-16052647
]
Hadoop QA commented on HBASE-16242:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 57s
{color} | {color:blue} Docker mode activated. {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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 27s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 40s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
58s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 3s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
3s {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} xml {color} | {color:green} 0m 4s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
33m 29s {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-alpha3. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 59s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m 50s
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 149m 28s
{color} | {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
5s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 221m 11s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.coprocessor.TestCoprocessorMetrics |
| | org.apache.hadoop.hbase.master.assignment.TestSplitTableRegionProcedure |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12873341/HBASE-16242.0.patch |
| JIRA Issue | HBASE-16242 |
| Optional Tests | asflicense javac javadoc unit xml compile |
| uname | Linux bfc49ae87b0a 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2
15:37:11 UTC 2016 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 / 4dc8051 |
| Default Java | 1.8.0_131 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/7211/artifact/patchprocess/patch-unit-root.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/7211/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7211/testReport/ |
| modules | C: hbase-common hbase-spark . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7211/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message
[jira] [Updated] (HBASE-18216) [AMv2] Workaround for HBASE-18152, corrupt procedure WAL
[ https://issues.apache.org/jira/browse/HBASE-18216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-18216: -- Attachment: HBASE-18216.branch-1.001.patch > [AMv2] Workaround for HBASE-18152, corrupt procedure WAL > > > Key: HBASE-18216 > URL: https://issues.apache.org/jira/browse/HBASE-18216 > Project: HBase > Issue Type: Bug > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-18216.branch-1.001.patch > > > Let me commit workaround for the issue up in HBASE-18152, corruption in the > master wal procedure files. Testing on cluster shows it helps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18152) [AMv2] Corrupt Procedure WAL file; procedure data stored out of order
[
https://issues.apache.org/jira/browse/HBASE-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052644#comment-16052644
]
stack commented on HBASE-18152:
---
Looks like we have a version of this problem in branch-1 too. This is from a
[~tsuna] 1.3.1 log:
{code}
2017-06-09 01:03:34,499 ERROR [r12s3:9102.activeMasterManager]
procedure2.ProcedureExecutor: corrupted procedure:
Procedure=org.apache.hadoop.hbase.master.procedure.ServerCrashProcedure (id=96,
owner=, state=RUNNABLE, startTime=6480hrs, 32mins, 51sec ago,
lastUpdate=6480hrs, 32mins, 51sec ago)
2017-06-09 01:03:34,499 ERROR [r12s3:9102.activeMasterManager]
procedure2.ProcedureExecutor: corrupted procedure:
Procedure=org.apache.hadoop.hbase.master.procedure.ServerCrashProcedure (id=15,
owner=, state=RUNNABLE, startTime=7032hrs, 28mins, 23sec ago,
lastUpdate=7032hrs, 28mins, 23sec ago)
2017-06-09 01:03:34,499 ERROR [r12s3:9102.activeMasterManager]
procedure2.ProcedureExecutor: corrupted procedure:
Procedure=org.apache.hadoop.hbase.master.procedure.ServerCrashProcedure (id=77,
owner=, state=RUNNABLE, startTime=7032hrs, 21mins, 11sec ago,
lastUpdate=7032hrs, 21mins, 11sec ago)
{code}
> [AMv2] Corrupt Procedure WAL file; procedure data stored out of order
> -
>
> Key: HBASE-18152
> URL: https://issues.apache.org/jira/browse/HBASE-18152
> Project: HBase
> Issue Type: Sub-task
> Components: Region Assignment
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-18152.master.001.patch,
> pv2-0036.log, pv2-0047.log,
> reading_bad_wal.patch
>
>
> I've seen corruption from time-to-time testing. Its rare enough. Often we
> can get over it but sometimes we can't. It took me a while to capture an
> instance of corruption. Turns out we are write to the WAL out-of-order which
> undoes a basic tenet; that WAL content is ordered in line w/ execution.
> Below I'll post a corrupt WAL.
> Looking at the write-side, there is a lot going on. I'm not clear on how we
> could write out of order. Will try and get more insight. Meantime parking
> this issue here to fill data into.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052643#comment-16052643
]
Hadoop QA commented on HBASE-18226:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 22s
{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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 14s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
56s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 3s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
28s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
35s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 4s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 4s
{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
27s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 3 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 3s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
35m 41s {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-alpha3. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 42s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 48s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 133m 48s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 190m 13s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.coprocessor.TestCoprocessorMetrics |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12873344/HBASE-18226.001.patch
|
| JIRA Issue | HBASE-18226 |
| Optional Tests | asflicense javac javadoc unit xml findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 6b7f791d81ca 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31
14:13:22 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 / cd478d1 |
| Default Java |
[jira] [Commented] (HBASE-18218) List replication peers for the cluster
[ https://issues.apache.org/jira/browse/HBASE-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052642#comment-16052642 ] Ted Yu commented on HBASE-18218: Should there be width limit for the Configuration column (in case there are many pairs in Configuration) ? > List replication peers for the cluster > -- > > Key: HBASE-18218 > URL: https://issues.apache.org/jira/browse/HBASE-18218 > Project: HBase > Issue Type: New Feature >Reporter: Ali >Assignee: Ali > Attachments: HBASE-18218.v1.branch-1.2.patch, > HBASE-18218.v2.branch-1.patch, HBASE-18218.v2.master.patch, screenshot-1.png, > screenshot-2.png > > > HBase Master page that listed all the replication peers for a cluster, with > their associated metadata -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18230) Generated LICENSE file includes unsubstituted Velocity variables
[
https://issues.apache.org/jira/browse/HBASE-18230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052641#comment-16052641
]
Hadoop QA commented on HBASE-18230:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 16m 33s
{color} | {color:blue} Docker mode activated. {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
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
6s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 5s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
5s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
7s {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} hadoopcheck {color} | {color:green}
29m 8s {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-alpha3. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 6s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 6s
{color} | {color:green} hbase-resource-bundle in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 49m 49s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12873354/HBASE-18230.patch |
| JIRA Issue | HBASE-18230 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux b1d57d9b0d60 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / cd478d1 |
| Default Java | 1.8.0_131 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7214/testReport/ |
| modules | C: hbase-resource-bundle U: hbase-resource-bundle |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7214/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Generated LICENSE file includes unsubstituted Velocity variables
>
>
> Key: HBASE-18230
> URL: https://issues.apache.org/jira/browse/HBASE-18230
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.0-alpha-1
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 1.4.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18230.patch
>
>
> From the release vote:
> {quote}
> we have a ton of places where we have velocity variables instead of
> copyright years, but IIRC that's a problem on branch-1 right now too.
> {quote}
> This is referring to lines like these:
> {noformat}
> * javax.annotation-api, ${dep.licenses[0].comments}
> * javax.servlet-api, ${dep.licenses[0].comments}
> * jetty-schemas, ${dep.licenses[0].comments}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052640#comment-16052640
]
Duo Xu commented on HBASE-18226:
{quote}
Maybe the master can only do forward DNS lookups and not reverse DNS
lookups?
{quote}
Yes. Forward DNS lookups is supported.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. In current implementation when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster as part of
> RegionServerStartupRequest. HMaster will not do reverse DNS lookup, which has
> been implemented in HBASE-12954. If users want to provide their own hostnames
> in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must
> be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-17752) Update reporting RPCs/Shell commands to break out space utilization by snapshot
[
https://issues.apache.org/jira/browse/HBASE-17752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052637#comment-16052637
]
Josh Elser commented on HBASE-17752:
bq. Nit: Can we estimate the size of this map before construction?
We can't. We're reading all of the serialized SpaceQuotaSnapshot objects for
hbase snapshots in the hbase:quota table. Given the context we have, there
could be zero or there could be 100's.
Cleaned up the rest and added a little test case. 003 incoming shortly.
> Update reporting RPCs/Shell commands to break out space utilization by
> snapshot
> ---
>
> Key: HBASE-17752
> URL: https://issues.apache.org/jira/browse/HBASE-17752
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: Josh Elser
> Attachments: HBASE-17752.001.patch, HBASE-17752.002.patch,
> HBASE-17752.003.patch
>
>
> For adminstrators running HBase with space quotas, it is useful to provide a
> breakdown of the utilization of a table. For example, it may be non-intuitive
> that a table's utilization is primarily made up of snapshots. We should
> provide a new command or modify existing commands such that an admin can see
> the utilization for a table/ns:
> e.g.
> {noformat}
> table1: 17GB
> resident: 10GB
> snapshot_a: 5GB
> snapshot_b: 2GB
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18136) Add Table::Delete(std::vector) method
[ https://issues.apache.org/jira/browse/HBASE-18136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-18136: --- Labels: native (was: ) > Add Table::Delete(std::vector) method > - > > Key: HBASE-18136 > URL: https://issues.apache.org/jira/browse/HBASE-18136 > Project: HBase > Issue Type: Sub-task >Reporter: Ted Yu > Labels: native > > HBASE-15903 adds support for single Delete object in Table API. > This subtask is to add support for vector of Delete objects in Table API. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052635#comment-16052635
]
Josh Elser commented on HBASE-18226:
bq. We do not want HMaster to do reverse DNS lookup because HMaster VM's
/etc/hosts does not have regionserver VM's FQDN mappings
bq. it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
bq. The patch simply stops HMaster doing reverse DNS lookup.
Without yet looking at the patch, this is a little worrisome. The rDNS lookup
by the Master is to prevent RS's from joining the cluster which don't have a
"stable" DNS. That is, if the Master cannot perform a DNS lookup on the IP of
the RS that is reporting for duty and get the same hostname that the RS
*thinks* it has, a client would also be very likely to get a different hostname.
Like Nick points out, when Kerberos is enabled, inconsistent DNS means the
cluster is unusable. RPCs over SASL with GSSAPI(krb5) require that the instance
component of the Kerberos principal match the hostname that a client used to
connect to a server. For example, if a RS has a principal
{{hbase/host1.domain.com}}, any RPC to that RS with a hostname *other than*
{{host1.domain.com}} is guaranteed to fail with an authentication error.
This all leads me to wonder how the Master presently sends RPCs to
RegionServers with Kerberos enabled on Azure. Maybe the master can only do
forward DNS lookups and not reverse DNS lookups? I think that would be a
plausible explanation.
Will try to take a look at the patch and give it some more thought.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. In current implementation when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster as part of
> RegionServerStartupRequest. HMaster will not do reverse DNS lookup, which has
> been implemented in HBASE-12954. If users want to provide their own hostnames
> in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must
> be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052632#comment-16052632
]
Duo Xu edited comment on HBASE-18226 at 6/17/17 1:59 AM:
-
[~ndimiduk]
Thanks for reviewing. I have not check secure HBase. I will setup and do some
sanity test.
Simply, my change is to use the hostname from RS rather than HMaster tells RS
to use the hostname which HMaster gets from reverse DNS lookup of the IP of the
connection socket. It should be no different from HBASE-12954, HBASE-12954 is
using the hostname user specified in the configuration.
I do not know much about secure HBase though, [~elserj] if you can help review
the patch too, that would be great!
was (Author: onpduo):
[~ndimiduk]
Thanks for reviewing. I have not check secure HBase. I will setup and do some
sanity test.
Simply, my change is to use the hostname from RS rather than HMaster tells RS
to use the hostname which HMaster gets from reverse DNS lookup of the IP of the
connection socket. It should be no different from HBASE-18226, HBASE-18226 is
using the hostname user specified in the configuration.
I do not know much about secure HBase though, [~elserj] if you can help review
the patch too, that would be great!
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. In current implementation when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster as part of
> RegionServerStartupRequest. HMaster will not do reverse DNS lookup, which has
> been implemented in HBASE-12954. If users want to provide their own hostnames
> in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must
> be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052632#comment-16052632
]
Duo Xu commented on HBASE-18226:
[~ndimiduk]
Thanks for reviewing. I have not check secure HBase. I will setup and do some
sanity test.
Simply, my change is to use the hostname from RS rather than HMaster tells RS
to use the hostname which HMaster gets from reverse DNS lookup of the IP of the
connection socket. It should be no different from HBASE-18226, HBASE-18226 is
using the hostname user specified in the configuration.
I do not know much about secure HBase though, [~elserj] if you can help review
the patch too, that would be great!
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. In current implementation when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster as part of
> RegionServerStartupRequest. HMaster will not do reverse DNS lookup, which has
> been implemented in HBASE-12954. If users want to provide their own hostnames
> in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must
> be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-16242) Upgrade Avro
[ https://issues.apache.org/jira/browse/HBASE-16242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-16242: -- Issue Type: Sub-task (was: Task) Parent: HBASE-17898 > Upgrade Avro > > > Key: HBASE-16242 > URL: https://issues.apache.org/jira/browse/HBASE-16242 > Project: HBase > Issue Type: Sub-task > Components: dependencies >Reporter: Ben McCann >Assignee: Sean Busbey > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-16242.0.patch > > > I'd like to see Avro upgraded to 1.8.1 or at the very least 1.7.7 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18230) Generated LICENSE file includes unsubstituted Velocity variables
[
https://issues.apache.org/jira/browse/HBASE-18230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-18230:
--
Attachment: HBASE-18230.patch
Patch that removes the velocity variables. Should go to all active branches.
> Generated LICENSE file includes unsubstituted Velocity variables
>
>
> Key: HBASE-18230
> URL: https://issues.apache.org/jira/browse/HBASE-18230
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.0-alpha-1
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 1.4.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18230.patch
>
>
> From the release vote:
> {quote}
> we have a ton of places where we have velocity variables instead of
> copyright years, but IIRC that's a problem on branch-1 right now too.
> {quote}
> This is referring to lines like these:
> {noformat}
> * javax.annotation-api, ${dep.licenses[0].comments}
> * javax.servlet-api, ${dep.licenses[0].comments}
> * jetty-schemas, ${dep.licenses[0].comments}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18230) Generated LICENSE file includes unsubstituted Velocity variables
[
https://issues.apache.org/jira/browse/HBASE-18230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-18230:
--
Fix Version/s: 2.0.0-alpha-2
1.4.0
Status: Patch Available (was: Open)
> Generated LICENSE file includes unsubstituted Velocity variables
>
>
> Key: HBASE-18230
> URL: https://issues.apache.org/jira/browse/HBASE-18230
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.0-alpha-1
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 1.4.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18230.patch
>
>
> From the release vote:
> {quote}
> we have a ton of places where we have velocity variables instead of
> copyright years, but IIRC that's a problem on branch-1 right now too.
> {quote}
> This is referring to lines like these:
> {noformat}
> * javax.annotation-api, ${dep.licenses[0].comments}
> * javax.servlet-api, ${dep.licenses[0].comments}
> * jetty-schemas, ${dep.licenses[0].comments}
> {noformat}
--
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 ] Mike Drob updated HBASE-18176: -- Status: Patch Available (was: In Progress) > 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: 2.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-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 ] Mike Drob updated HBASE-18176: -- Attachment: HBASE-18176.v2.patch v2: Address [~busbey]'s feedback. > 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: 2.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] [Created] (HBASE-18230) Generated LICENSE file includes unsubstituted Velocity variables
Mike Drob created HBASE-18230:
-
Summary: Generated LICENSE file includes unsubstituted Velocity
variables
Key: HBASE-18230
URL: https://issues.apache.org/jira/browse/HBASE-18230
Project: HBase
Issue Type: Bug
Components: build
Affects Versions: 2.0.0-alpha-1
Reporter: Mike Drob
Assignee: Mike Drob
>From the release vote:
{quote}
we have a ton of places where we have velocity variables instead of
copyright years, but IIRC that's a problem on branch-1 right now too.
{quote}
This is referring to lines like these:
{noformat}
* javax.annotation-api, ${dep.licenses[0].comments}
* javax.servlet-api, ${dep.licenses[0].comments}
* jetty-schemas, ${dep.licenses[0].comments}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052603#comment-16052603
]
Nick Dimiduk commented on HBASE-18226:
--
What are the impacts of this kind of change on a Kerberos enabled environment?
On first glance, it sounds like your target deployment environment doesn't work
for Kerberos at all, but [~elserj] knows more of those nuances than I.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. In current implementation when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster as part of
> RegionServerStartupRequest. HMaster will not do reverse DNS lookup, which has
> been implemented in HBASE-12954. If users want to provide their own hostnames
> in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must
> be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052595#comment-16052595
]
Duo Xu edited comment on HBASE-18226 at 6/17/17 12:49 AM:
--
[~enis]
Could you take a look at this patch? Do I need to set the affected version
field to kick off the QA build?
I locally compiled the jar and replaced on my cluster (which does not support
reverse DNS lookup),
1. without adding FQDN entry in /etc/hosts for regionserver VMs, regionserver
will use IP as part of its server name.
2. After adding FQDN entry in /etc/hosts for regionserver VMs, regionserver
will use FQDN as part of its server name.
was (Author: onpduo):
[~enis]
Could you take a look at this patch? Do I need to set the affected version
field to kick off the QA build?
I locally compiled the jar and replaced on my cluster (which does not support
reverse DNS lookup),
1. without adding FQDN entry in /etc/hosts, regionserver will use IP as part of
its server name.
2. After adding FQDN entry in /etc/hosts, regionserver will use FQDN as part of
its server name.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. In current implementation when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster as part of
> RegionServerStartupRequest. HMaster will not do reverse DNS lookup, which has
> been implemented in HBASE-12954. If users want to provide their own hostnames
> in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must
> be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052595#comment-16052595
]
Duo Xu commented on HBASE-18226:
[~enis]
Could you take a look at this patch? Do I need to set the affected version
field to kick off the QA build?
I locally compiled the jar and replaced on my cluster (which does not support
reverse DNS lookup),
1. without adding FQDN entry in /etc/hosts, regionserver will use IP as part of
its server name.
2. After adding FQDN entry in /etc/hosts, regionserver will use FQDN as part of
its server name.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. In current implementation when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster as part of
> RegionServerStartupRequest. HMaster will not do reverse DNS lookup, which has
> been implemented in HBASE-12954. If users want to provide their own hostnames
> in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must
> be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[ https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052574#comment-16052574 ] Duo Xu edited comment on HBASE-18226 at 6/17/17 12:40 AM: -- [~esteban] Sorry for the confusion. Let me explain more clearly. 1. HBASE-12954 provided a configuration called "hbase.regionserver.hostname" so users can use whatever hostname they preferred for each regionserver/node. That means each regionserver/node needs a different copy of hbase-site.xml. Because the value of "hbase.regionserver.hostname" is different for different nodes. Ambari or any other configuration management tool does not support to set different values of a setting on different nodes. Thus HBASE-12954 introduced configuration does not work with any configuration management tool. 2. This JIRA intends to let RS uses the value returned by getHostName() rather than users specify it and send it as part of RegionServerStartupRequest to HMaster, so HMaster will use this hostname instead of doing reverse DNS lookup as some cloud environment does not provide reverse DNS lookup for the VMs. This part has been implemented in HBASE-12954. 3. In Azure HDInsight clusters cloud setup, we want to give each regionserver node a FQDN by modifying /etc/hosts on that node (this is done by our deployment service). In my testing, without modifying /etc/hosts (our current setting), getHostName() will return IP of the VM, after adding the FQDN entry, it returns the FQDN. However, since each VM's host file only contains itself FQDN entry, reverse DNS lookup won't work on HMaster side to get the RS FQDN. This is the issue we want to resolve, we do not want HMaster to do reverse DNS lookup. 4. Thus this JIRA is not to ask you to change /etc/hosts. The patch simply stops HMaster doing reverse DNS lookup. The introduced configuration is more coniguration management tool friendly and tells RS to use the value return by getHostName() as the hostname and send to HMaster. So comparing with HBASE-12954, the goal is slightly different HBASE-12954 provides users options to give whatever hostname they want to each regionserver and disable reverse DNS lookup on HMaster side. Configuration management tools will not support this configuration because each node needs a different value. This JIRA provides users options to use the value returned by getHostName(), which is the current default option in HBase, to HMaster and disable reverse DNS lookup on HMaster side (without this patch, it will do reverse DNS lookup). Configuration management tools will support this configuration because it is a true/false value, users do not need to explicitly set the hostname for each node. was (Author: onpduo): [~esteban] Sorry for the confusion. Let me explain more clearly. 1. HBASE-12954 provided a configuration called "hbase.regionserver.hostname" so users can use whatever hostname they preferred for each regionserver/node. That means each regionserver/node needs a different copy of hbase-site.xml. Because the value of "hbase.regionserver.hostname" is different for different nodes. Ambari or any other configuration management tool does not support to set different values of a setting on different nodes. Thus HBASE-12954 introduced configuration does not work with any configuration management tool. 2. This JIRA intends to let RS uses the value returned by getHostName() rather than users specify it and send it as part of RegionServerStartupRequest to HMaster, so HMaster will use this hostname instead of doing reverse DNS lookup as some cloud environment does not provide reverse DNS lookup for the VMs. This part has been implemented in HBASE-12954. 3. In Azure HDInsight clusters cloud setup, we want to give each regionserver node a FQDN by modifying /etc/hosts on that node. In my testing, without modifying /etc/hosts (our current setting), getHostName() will return IP of the VM, after adding the FQDN entry, it returns the FQDN. However, since each VM's host file only contains itself FQDN entry, reverse DNS lookup won't work on HMaster side to get the RS FQDN. This is the issue we want to resolve, we do not want HMaster to do reverse DNS lookup. 4. Thus this JIRA is not to ask you to change /etc/hosts. The patch simply stops HMaster doing reverse DNS lookup. The introduced configuration is more coniguration management tool friendly and tells RS to use the value return by getHostName() as the hostname and send to HMaster. So comparing with HBASE-12954, the goal is slightly different HBASE-12954 provides users options to give whatever hostname they want to each regionserver and disable reverse DNS lookup on HMaster side. Configuration management tools will not support this configuration because each node needs a different value. This JIRA provides users options to use the value returned by getHostName(), which
[jira] [Comment Edited] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[ https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052574#comment-16052574 ] Duo Xu edited comment on HBASE-18226 at 6/17/17 12:38 AM: -- [~esteban] Sorry for the confusion. Let me explain more clearly. 1. HBASE-12954 provided a configuration called "hbase.regionserver.hostname" so users can use whatever hostname they preferred for each regionserver/node. That means each regionserver/node needs a different copy of hbase-site.xml. Because the value of "hbase.regionserver.hostname" is different for different nodes. Ambari or any other configuration management tool does not support to set different values of a setting on different nodes. Thus HBASE-12954 introduced configuration does not work with any configuration management tool. 2. This JIRA intends to let RS uses the value returned by getHostName() rather than users specify it and send it as part of RegionServerStartupRequest to HMaster, so HMaster will use this hostname instead of doing reverse DNS lookup as some cloud environment does not provide reverse DNS lookup for the VMs. This part has been implemented in HBASE-12954. 3. In Azure HDInsight clusters cloud setup, we want to give each regionserver node a FQDN by modifying /etc/hosts on that node. In my testing, without modifying /etc/hosts (our current setting), getHostName() will return IP of the VM, after adding the FQDN entry, it returns the FQDN. However, since each VM's host file only contains itself FQDN entry, reverse DNS lookup won't work on HMaster side to get the RS FQDN. This is the issue we want to resolve, we do not want HMaster to do reverse DNS lookup. 4. Thus this JIRA is not to ask you to change /etc/hosts. The patch simply stops HMaster doing reverse DNS lookup. The introduced configuration is more coniguration management tool friendly and tells RS to use the value return by getHostName() as the hostname and send to HMaster. So comparing with HBASE-12954, the goal is slightly different HBASE-12954 provides users options to give whatever hostname they want to each regionserver and disable reverse DNS lookup on HMaster side. Configuration management tools will not support this configuration because each node needs a different value. This JIRA provides users options to use the value returned by getHostName(), which is the current default option in HBase, to HMaster and disable reverse DNS lookup on HMaster side (without this patch, it will do reverse DNS lookup). Configuration management tools will support this configuration because it is a true/false value, users do not need to explicitly set the hostname for each node. was (Author: onpduo): [~esteban] Sorry for the confusion. Let me explain more clearly. 1. HBASE-12954 provided a configuration called "hbase.regionserver.hostname" so users can use whatever hostname they preferred for each regionserver/node. That means each regionserver/node needs a different copy of hbase-site.xml. Because the value of "hbase.regionserver.hostname" is different for different nodes. Ambari or any other configuration management tool does not support to set different values of a setting on different nodes. Thus HBASE-12954 introduced configuration does not work with any configuration management tool. 2. This JIRA intends to let RS uses the value returned by getHostName() rather than users specify it and send it as part of RegionServerStartupRequest to HMaster, so HMaster will use this hostname instead of doing reverse DNS lookup as some cloud environment does not provide reverse DNS lookup for the VMs. This part has been implemented in HBASE-12954. 3. In Azure HDInsight clusters cloud setup, we want to give each regionserver node a FQDN by modifying /etc/hosts on that node. In my testing, without modifying /etc/hosts (our current setting), getHostName() will return IP of the VM, after adding the FQDN entry, it returns the FQDN. However, since each VM's host file only contains itself FQDN entry, reverse DNS lookup won't work on HMaster side to get the RS FQDN. This is the issue we want to resolve, we do not want HMaster to do reverse DNS lookup. So comparing with HBASE-12954, the goal is slightly different HBASE-12954 provides users options to give whatever hostname they want to each regionserver and disable reverse DNS lookup on HMaster side. Configuration management tools will not support this configuration because each node needs a different value. This JIRA provides users options to use the value returned by getHostName(), which is the current default option in HBase, to HMaster and disable reverse DNS lookup on HMaster side (without this patch, it will do reverse DNS lookup). Configuration management tools will support this configuration because it is a true/false value, users do not need to explicitly set the hostname for each node. > Disable
[jira] [Updated] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Xu updated HBASE-18226:
---
Description:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse
DNS lookup because HMaster VM's /etc/hosts does not have regionserver VM's FQDN
mappings. In current implementation when regionserver starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster as part of . HMaster will not do reverse DNS lookup, which has
been implemented in HBASE-12954. If users want to provide their own hostnames
in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must
be false.
I will submit a patch later today.
was:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse
DNS lookup because HMaster VM's /etc/hosts does not have regionserver VM's FQDN
mappings. In current implementation when regionserver starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster. HMaster will not do reverse DNS lookup, which has been
implemented in HBASE-12954. If users want to provide their own hostnames in
"*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be
false.
I will submit a patch later today.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. In current implementation when regionserver starts,
> {code}
> String hostName =
[jira] [Updated] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Xu updated HBASE-18226:
---
Description:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse
DNS lookup because HMaster VM's /etc/hosts does not have regionserver VM's FQDN
mappings. In current implementation when regionserver starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster as part of RegionServerStartupRequest. HMaster will not do
reverse DNS lookup, which has been implemented in HBASE-12954. If users want to
provide their own hostnames in "*hbase.regionserver.hostname*",
"*hbase.regionserver.hostname.auto*" must be false.
I will submit a patch later today.
was:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse
DNS lookup because HMaster VM's /etc/hosts does not have regionserver VM's FQDN
mappings. In current implementation when regionserver starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster as part of . HMaster will not do reverse DNS lookup, which has
been implemented in HBASE-12954. If users want to provide their own hostnames
in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must
be false.
I will submit a patch later today.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. In current implementation when regionserver starts,
> {code}
>
[jira] [Updated] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Xu updated HBASE-18226:
---
Description:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse
DNS lookup because HMaster VM's /etc/hosts does not have regionserver VM's FQDN
mappings. In current implementation when regionserver starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster. HMaster will not do reverse DNS lookup, which has been
implemented in HBASE-12954. If users want to provide their own hostnames in
"*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be
false.
I will submit a patch later today.
was:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse
DNS lookup because HMaster VM's /etc/hosts does not have regionserver VM's FQDN
mappings. When regionserver starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster. HMaster will not do reverse DNS lookup, which has been
implemented in HBASE-12954. If users want to provide their own hostnames in
"*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be
false.
I will submit a patch later today.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. In current implementation when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
>
[jira] [Updated] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Xu updated HBASE-18226:
---
Description:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse
DNS lookup because HMaster VM's /etc/hosts does not have regionserver VM's FQDN
mappings. When regionserver starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster. HMaster will not do reverse DNS lookup, which has been
implemented in HBASE-12954. If users want to provide their own hostnames in
"*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be
false.
I will submit a patch later today.
was:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse
DNS lookup because that will not resolves to FQDN we want. When regionserver
starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster. HMaster will not do reverse DNS lookup, which has been
implemented in HBASE-12954. If users want to provide their own hostnames in
"*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be
false.
I will submit a patch later today.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver
> VM's FQDN mappings. When regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on
[jira] [Updated] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Xu updated HBASE-18226:
---
Description:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse
DNS lookup because that will not resolves to FQDN we want. When regionserver
starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster. HMaster will not do reverse DNS lookup, which has been
implemented in HBASE-12954. If users want to provide their own hostnames in
"*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be
false.
I will submit a patch later today.
was:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node so we do not want HMaster to do
reverse DNS lookup because that will not resolves to FQDN we want. When
regionserver starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster. HMaster will not do reverse DNS lookup, which has been
implemented in HBASE-12954. If users want to provide their own hostnames in
"*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be
false.
I will submit a patch later today.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do
> reverse DNS lookup because that will not resolves to FQDN we want. When
> regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be
[jira] [Updated] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Xu updated HBASE-18226:
---
Description:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari or other configuration
management tools because each regionserver has a different value of this
setting, which means each node needs a different hbase-site.xml.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node so we do not want HMaster to do
reverse DNS lookup because that will not resolves to FQDN we want. When
regionserver starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster. HMaster will not do reverse DNS lookup, which has been
implemented in HBASE-12954. If users want to provide their own hostnames in
"*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be
false.
I will submit a patch later today.
was:
This JIRA is to address the similar problem as HBASE-12954, but there are some
little differences,
1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
users can configure it on every regionserver with preferred hostnames. However,
this configuration cannot be set through Ambari because each regionserver has a
different value of this setting.
2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a
FQDN by modifying /etc/hosts on that node, then when regionserver starts,
{code}
String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
rpcServices.isa.getHostName();
{code}
it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
which cannot be resolved.
{code}
// if regionserver passed hostname to use,
// then use it instead of doing a reverse DNS lookup
ServerName rs = master.getServerManager().regionServerStartup(request, ia);
{code}
My proposed fix is to add a new configuration
"*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
will use the value returned by *rpcServices.isa.getHostName()* as the hostname
overwriting whatever users specifies in "*hbase.regionserver.hostname*" and
send to HMaster. HMaster will not do reverse DNS lookup, which has been
implemented in HBASE-12954. If users want to provide their own hostnames in
"*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be
false.
I will submit a patch later today.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari or other
> configuration management tools because each regionserver has a different
> value of this setting, which means each node needs a different hbase-site.xml.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node so we do not want HMaster to do
> reverse DNS lookup because that will not resolves to FQDN we want. When
> regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs =
[jira] [Commented] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052574#comment-16052574
]
Duo Xu commented on HBASE-18226:
[~esteban]
Sorry for the confusion. Let me explain more clearly.
1. HBASE-12954 provided a configuration called "hbase.regionserver.hostname"
so users can use whatever hostname they preferred for each regionserver/node.
That means each regionserver/node needs a different copy of hbase-site.xml.
Because the value of "hbase.regionserver.hostname" is different for different
nodes. Ambari or any other configuration management tool does not support to
set different values of a setting on different nodes. Thus HBASE-12954
introduced configuration does not work with any configuration management tool.
2. This JIRA intends to let RS uses the value returned by getHostName() rather
than users specify it and send it as part of RegionServerStartupRequest to
HMaster, so HMaster will use this hostname instead of doing reverse DNS lookup
as some cloud environment does not provide reverse DNS lookup for the VMs. This
part has been implemented in HBASE-12954.
3. In Azure HDInsight clusters cloud setup, we want to give each regionserver
node a FQDN by modifying /etc/hosts on that node. In my testing, without
modifying /etc/hosts (our current setting), getHostName() will return IP of the
VM, after adding the FQDN entry, it returns the FQDN. However, since each VM's
host file only contains itself FQDN entry, reverse DNS lookup won't work on
HMaster side to get the RS FQDN. This is the issue we want to resolve, we do
not want HMaster to do reverse DNS lookup.
So comparing with HBASE-12954, the goal is slightly different
HBASE-12954 provides users options to give whatever hostname they want to each
regionserver and disable reverse DNS lookup on HMaster side. Configuration
management tools will not support this configuration because each node needs a
different value.
This JIRA provides users options to use the value returned by getHostName(),
which is the current default option in HBase, to HMaster and disable reverse
DNS lookup on HMaster side (without this patch, it will do reverse DNS lookup).
Configuration management tools will support this configuration because it is a
true/false value, users do not need to explicitly set the hostname for each
node.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari because each
> regionserver has a different value of this setting.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node, then when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster. HMaster will not do
> reverse DNS lookup, which has been implemented in HBASE-12954. If users want
> to provide their own hostnames in "*hbase.regionserver.hostname*",
> "*hbase.regionserver.hostname.auto*" must be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052545#comment-16052545
]
Hadoop QA commented on HBASE-18227:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 20s
{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 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 42s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 42s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 42s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
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} hadoopcheck {color} | {color:green}
27m 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-alpha3. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
54s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 111m 55s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 153m 24s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestMasterProcedureWalLease |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12873335/HBASE-18227.master.001.patch
|
| JIRA Issue | HBASE-18227 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 2a493f012060 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / 4dc8051 |
| Default Java | 1.8.0_131 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/7209/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/7209/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7209/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7209/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
[jira] [Commented] (HBASE-18170) Refactor ReplicationSourceWALReaderThread
[ https://issues.apache.org/jira/browse/HBASE-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052539#comment-16052539 ] Guanghao Zhang commented on HBASE-18170: TestCoprocessorMetrics is not related and there is a issue HBASE-18222 which try to fix it. [~tedyu] [~apurtell] [~chia7712] Can you to help review this? Thanks. > Refactor ReplicationSourceWALReaderThread > - > > Key: HBASE-18170 > URL: https://issues.apache.org/jira/browse/HBASE-18170 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-18170.master.001.patch, > HBASE-18170.master.001.patch, HBASE-18170.master.002.patch, > HBASE-18170.master.002.patch, HBASE-18170.master.003.patch > > > HBASE-18130 add some get* method to ReplicationSource. So > ReplicationSourceWALReaderThread doesn't need so many parameter to > initialize. And the WALEntryFilter only used by > ReplicationSourceWALReaderThread, so we don't need to new it for every > ReplicationSourceWALReaderThread. Meanwhile, we can separate a new > RecoveredReplicationSourceWALReaderThread for recovered replication source. > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18218) List replication peers for the cluster
[ https://issues.apache.org/jira/browse/HBASE-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali updated HBASE-18218: Status: Open (was: Patch Available) > List replication peers for the cluster > -- > > Key: HBASE-18218 > URL: https://issues.apache.org/jira/browse/HBASE-18218 > Project: HBase > Issue Type: New Feature >Reporter: Ali >Assignee: Ali > Attachments: HBASE-18218.v1.branch-1.2.patch, > HBASE-18218.v2.branch-1.patch, HBASE-18218.v2.master.patch, screenshot-1.png, > screenshot-2.png > > > HBase Master page that listed all the replication peers for a cluster, with > their associated metadata -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052530#comment-16052530
]
Esteban Gutierrez commented on HBASE-18226:
---
[~onpduo], can you please elaborate more how can this help other deployments
without Ambari? I think modifying /etc/hosts is a terrible way to address this
problem. The RS should be provided via gethostname or not at all. If Ambari or
any other configuration management tool doesn't support providing the desired
hostname for a configuration that we already have, that means that those
configuration management tools should add a way to support our feature instead
of HBase providing a workaround for a missing feature from those tools. Thanks.
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari because each
> regionserver has a different value of this setting.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node, then when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster. HMaster will not do
> reverse DNS lookup, which has been implemented in HBASE-12954. If users want
> to provide their own hostnames in "*hbase.regionserver.hostname*",
> "*hbase.regionserver.hostname.auto*" must be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18218) List replication peers for the cluster
[
https://issues.apache.org/jira/browse/HBASE-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052523#comment-16052523
]
Hadoop QA commented on HBASE-18218:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 17m 19s
{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
34s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s
{color} | {color:green} branch-1 passed with JDK v1.8.0_131 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s
{color} | {color:green} branch-1 passed with JDK v1.7.0_131 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
38s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 3 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
14m 44s {color} | {color:green} The patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
13s {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_131 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed with JDK v1.7.0_131 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 95m 48s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
27s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 139m 32s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.TestMasterStatusServlet |
| | hadoop.hbase.regionserver.TestRSKilledWhenInitializing |
| | hadoop.hbase.client.TestReplicasClient |
| | hadoop.hbase.regionserver.TestCompactionInDeadRegionServer |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:395d9a0 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12873334/HBASE-18218.v2.branch-1.patch
|
| JIRA Issue | HBASE-18218 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux a4df596933ab 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/patchprocess/precommit/personality/hbase.sh |
| git revision | branch-1 / 316e02e |
| Default Java | 1.7.0_131 |
| Multi-JDK versions | /usr/lib/jvm/java-8-oracle:1.8.0_131
/usr/lib/jvm/java-7-openjdk-amd64:1.7.0_131 |
| whitespace |
https://builds.apache.org/job/PreCommit-HBASE-Build/7208/artifact/patchprocess/whitespace-eol.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/7208/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/7208/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7208/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7208/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> List replication peers for the cluster
> --
>
> Key: HBASE-18218
>
[jira] [Updated] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Xu updated HBASE-18226:
---
Status: Patch Available (was: Open)
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari because each
> regionserver has a different value of this setting.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node, then when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster. HMaster will not do
> reverse DNS lookup, which has been implemented in HBASE-12954. If users want
> to provide their own hostnames in "*hbase.regionserver.hostname*",
> "*hbase.regionserver.hostname.auto*" must be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Xu updated HBASE-18226:
---
Attachment: HBASE-18226.001.patch
> Disable reverse DNS lookup at HMaster and use default hostname provided by
> RegionServer
> ---
>
> Key: HBASE-18226
> URL: https://issues.apache.org/jira/browse/HBASE-18226
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Xu
> Attachments: HBASE-18226.001.patch
>
>
> This JIRA is to address the similar problem as HBASE-12954, but there are
> some little differences,
> 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so
> users can configure it on every regionserver with preferred hostnames.
> However, this configuration cannot be set through Ambari because each
> regionserver has a different value of this setting.
> 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode
> a FQDN by modifying /etc/hosts on that node, then when regionserver starts,
> {code}
> String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead :
> rpcServices.isa.getHostName();
> {code}
> it uses FQDN names here but on HMaster side, it will do reverse DNS lookup
> which cannot be resolved.
> {code}
> // if regionserver passed hostname to use,
> // then use it instead of doing a reverse DNS lookup
> ServerName rs = master.getServerManager().regionServerStartup(request, ia);
> {code}
> My proposed fix is to add a new configuration
> "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver
> will use the value returned by *rpcServices.isa.getHostName()* as the
> hostname overwriting whatever users specifies in
> "*hbase.regionserver.hostname*" and send to HMaster. HMaster will not do
> reverse DNS lookup, which has been implemented in HBASE-12954. If users want
> to provide their own hostnames in "*hbase.regionserver.hostname*",
> "*hbase.regionserver.hostname.auto*" must be false.
> I will submit a patch later today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-17996) HBase master fails to start sometimes on RHEL7
[
https://issues.apache.org/jira/browse/HBASE-17996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052503#comment-16052503
]
Jonathan Hsieh commented on HBASE-17996:
Thanks [~elserj]!
> HBase master fails to start sometimes on RHEL7
> --
>
> Key: HBASE-17996
> URL: https://issues.apache.org/jira/browse/HBASE-17996
> Project: HBase
> Issue Type: Bug
> Components: master, test
>Reporter: David Knupp
> Attachments:
> hbase-jenkins-master-impala-boost-static-burst-slave-el7-02f4.vpc.cloudera.com.out,
>
> hbase-jenkins-master-impala-boost-static-burst-slave-el7-11ef.vpc.cloudera.com.out
>
>
> Impala includes HBase in its local test environment, and we have found that
> intermittently, the HBase master node fails to start when we are testing on
> RHEL7.
> In these failures, what we typically see in the logs is this:
> {noformat}
> 17/04/29 21:33:47 INFO zookeeper.ClientCnxn: Session establishment complete
> on server localhost/0:0:0:0:0:0:0:1:2181, sessionid = 0x15bbd21b797000a,
> negotiated timeout = 9
> 17/04/29 21:33:47 INFO client.ZooKeeperRegistry: ClusterId read in ZooKeeper
> is null
> 17/04/29 21:33:48 INFO master.ActiveMasterManager: Deleting ZNode for
> /hbase/backup-masters/localhost,16000,1493526758211 from backup master
> directory
> {noformat}
> On a successful startup, the log looks like this:
> {noformat}
> 17/04/16 21:32:29 INFO zookeeper.ClientCnxn: Session establishment complete
> on server localhost/0:0:0:0:0:0:0:1:2181, sessionid = 0x15b7a2ed6860005,
> negotiated timeout = 9
> 17/04/16 21:32:29 INFO client.ZooKeeperRegistry: ClusterId read in ZooKeeper
> is null
> 17/04/16 21:32:30 INFO util.FSUtils: Created version file at
> hdfs://localhost:20500/hbase with version=8
> 17/04/16 21:32:31 INFO master.MasterFileSystem: BOOTSTRAP: creating
> hbase:meta region
> {noformat}
> So the event that we don't see in the failed start up attempts is
> {{master.MasterFileSystem: BOOTSTRAP: creating hbase:meta region}}.
> The full logs will be attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-17996) HBase master fails to start sometimes on RHEL7
[
https://issues.apache.org/jira/browse/HBASE-17996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved HBASE-17996.
Resolution: Won't Fix
Flipped this from "Fixed" to "Won't Fix" to avoid any confusion about whether
or not there was a code-change in HBase.
> HBase master fails to start sometimes on RHEL7
> --
>
> Key: HBASE-17996
> URL: https://issues.apache.org/jira/browse/HBASE-17996
> Project: HBase
> Issue Type: Bug
> Components: master, test
>Reporter: David Knupp
> Attachments:
> hbase-jenkins-master-impala-boost-static-burst-slave-el7-02f4.vpc.cloudera.com.out,
>
> hbase-jenkins-master-impala-boost-static-burst-slave-el7-11ef.vpc.cloudera.com.out
>
>
> Impala includes HBase in its local test environment, and we have found that
> intermittently, the HBase master node fails to start when we are testing on
> RHEL7.
> In these failures, what we typically see in the logs is this:
> {noformat}
> 17/04/29 21:33:47 INFO zookeeper.ClientCnxn: Session establishment complete
> on server localhost/0:0:0:0:0:0:0:1:2181, sessionid = 0x15bbd21b797000a,
> negotiated timeout = 9
> 17/04/29 21:33:47 INFO client.ZooKeeperRegistry: ClusterId read in ZooKeeper
> is null
> 17/04/29 21:33:48 INFO master.ActiveMasterManager: Deleting ZNode for
> /hbase/backup-masters/localhost,16000,1493526758211 from backup master
> directory
> {noformat}
> On a successful startup, the log looks like this:
> {noformat}
> 17/04/16 21:32:29 INFO zookeeper.ClientCnxn: Session establishment complete
> on server localhost/0:0:0:0:0:0:0:1:2181, sessionid = 0x15b7a2ed6860005,
> negotiated timeout = 9
> 17/04/16 21:32:29 INFO client.ZooKeeperRegistry: ClusterId read in ZooKeeper
> is null
> 17/04/16 21:32:30 INFO util.FSUtils: Created version file at
> hdfs://localhost:20500/hbase with version=8
> 17/04/16 21:32:31 INFO master.MasterFileSystem: BOOTSTRAP: creating
> hbase:meta region
> {noformat}
> So the event that we don't see in the failed start up attempts is
> {{master.MasterFileSystem: BOOTSTRAP: creating hbase:meta region}}.
> The full logs will be attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (HBASE-17996) HBase master fails to start sometimes on RHEL7
[
https://issues.apache.org/jira/browse/HBASE-17996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reopened HBASE-17996:
> HBase master fails to start sometimes on RHEL7
> --
>
> Key: HBASE-17996
> URL: https://issues.apache.org/jira/browse/HBASE-17996
> Project: HBase
> Issue Type: Bug
> Components: master, test
>Reporter: David Knupp
> Attachments:
> hbase-jenkins-master-impala-boost-static-burst-slave-el7-02f4.vpc.cloudera.com.out,
>
> hbase-jenkins-master-impala-boost-static-burst-slave-el7-11ef.vpc.cloudera.com.out
>
>
> Impala includes HBase in its local test environment, and we have found that
> intermittently, the HBase master node fails to start when we are testing on
> RHEL7.
> In these failures, what we typically see in the logs is this:
> {noformat}
> 17/04/29 21:33:47 INFO zookeeper.ClientCnxn: Session establishment complete
> on server localhost/0:0:0:0:0:0:0:1:2181, sessionid = 0x15bbd21b797000a,
> negotiated timeout = 9
> 17/04/29 21:33:47 INFO client.ZooKeeperRegistry: ClusterId read in ZooKeeper
> is null
> 17/04/29 21:33:48 INFO master.ActiveMasterManager: Deleting ZNode for
> /hbase/backup-masters/localhost,16000,1493526758211 from backup master
> directory
> {noformat}
> On a successful startup, the log looks like this:
> {noformat}
> 17/04/16 21:32:29 INFO zookeeper.ClientCnxn: Session establishment complete
> on server localhost/0:0:0:0:0:0:0:1:2181, sessionid = 0x15b7a2ed6860005,
> negotiated timeout = 9
> 17/04/16 21:32:29 INFO client.ZooKeeperRegistry: ClusterId read in ZooKeeper
> is null
> 17/04/16 21:32:30 INFO util.FSUtils: Created version file at
> hdfs://localhost:20500/hbase with version=8
> 17/04/16 21:32:31 INFO master.MasterFileSystem: BOOTSTRAP: creating
> hbase:meta region
> {noformat}
> So the event that we don't see in the failed start up attempts is
> {{master.MasterFileSystem: BOOTSTRAP: creating hbase:meta region}}.
> The full logs will be attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-16242) Upgrade Avro
[ https://issues.apache.org/jira/browse/HBASE-16242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-16242: Fix Version/s: 2.0.0-alpha-2 3.0.0 Release Note: Apache HBase now specifies that version 1.7.7 of the Apache Avro library should be pulled in by maven and included in the convenience binary tarball. Status: Patch Available (was: Open) include in branch-1 as well, what do you think [~jerryhe]? > Upgrade Avro > > > Key: HBASE-16242 > URL: https://issues.apache.org/jira/browse/HBASE-16242 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Ben McCann >Assignee: Sean Busbey > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-16242.0.patch > > > I'd like to see Avro upgraded to 1.8.1 or at the very least 1.7.7 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17766) Generate Javadoc for hbase-spark module
[
https://issues.apache.org/jira/browse/HBASE-17766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052483#comment-16052483
]
Yi Liang commented on HBASE-17766:
--
Hi Sean,
{quote}Are we looking at this wrong? {quote}
Let me do some research in scaladoc, the problem might be the integration
between maven tool and scaladoc.
> 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: 2.0.0
>
> Attachments: HBASE-17766-V1.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-16242) Upgrade Avro
[ https://issues.apache.org/jira/browse/HBASE-16242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-16242: Attachment: HBASE-16242.0.patch -0 - set avro version in management section at top level - rely on top level management for version in hbase-spark - promote transitive dependency in hbase-common to first-level so we can set the version > Upgrade Avro > > > Key: HBASE-16242 > URL: https://issues.apache.org/jira/browse/HBASE-16242 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Ben McCann >Assignee: Sean Busbey > Attachments: HBASE-16242.0.patch > > > I'd like to see Avro upgraded to 1.8.1 or at the very least 1.7.7 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-16242) Upgrade Avro
[ https://issues.apache.org/jira/browse/HBASE-16242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reassigned HBASE-16242: --- Assignee: Sean Busbey > Upgrade Avro > > > Key: HBASE-16242 > URL: https://issues.apache.org/jira/browse/HBASE-16242 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Ben McCann >Assignee: Sean Busbey > > I'd like to see Avro upgraded to 1.8.1 or at the very least 1.7.7 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Liang updated HBASE-18229: - Attachment: HBase-18229-master-v1.patch > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang > Attachments: HBase-18229-master-v1.patch > > > See HBASE-18105 for related information, this jira will change the logic of > Path 1 in splitProcedure, the execution path will be: > *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> > MasterRpcServices.splitRegion -> HMaster.splitRegion-> > AssignmentManager.submitProcedure* > Master Will no longer as Rs and then Rs turn around to ask master to do the > split operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Liang updated HBASE-18229: - Status: Patch Available (was: Open) > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang > Attachments: HBase-18229-master-v1.patch > > > See HBASE-18105 for related information, this jira will change the logic of > Path 1 in splitProcedure, the execution path will be: > *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> > MasterRpcServices.splitRegion -> HMaster.splitRegion-> > AssignmentManager.submitProcedure* > Master Will no longer as Rs and then Rs turn around to ask master to do the > split operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052468#comment-16052468 ] Yi Liang commented on HBASE-18229: -- Hi [~stack], I just finished the patch of creating new AsyncSplit Api, and this API goes to HBaseAdmin. Will add those api to AsyncHBaseAdmin as well in next patch, just upload this draft one to see if it can passs the tests. When input splitRow is null, I add a new rpc call (GetBestSplitPointResponse) instead of add to the GetRegionInfoResponse protobuf > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang > > See HBASE-18105 for related information, this jira will change the logic of > Path 1 in splitProcedure, the execution path will be: > *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> > MasterRpcServices.splitRegion -> HMaster.splitRegion-> > AssignmentManager.submitProcedure* > Master Will no longer as Rs and then Rs turn around to ask master to do the > split operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18228) HBCK improvements
[ https://issues.apache.org/jira/browse/HBASE-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18228: Fix Version/s: 1.4.0 > HBCK improvements > - > > Key: HBASE-18228 > URL: https://issues.apache.org/jira/browse/HBASE-18228 > Project: HBase > Issue Type: Improvement > Components: hbck >Reporter: Lars Hofhansl >Priority: Critical > Fix For: 1.4.0 > > > We just had a prod issue and running HBCK the way we did actually causes more > problems. > In part HBCK did stuff we did not expect, in part we had little visibility > into what HBCK was doing, and in part the logging was confusing. > I'm proposing 2 improvements: > 1. A dry-run mode. Run, and just list what would have been done. > 2. An interactive mode. Run, and for each action request Y/N user input. So > that a user can opt-out of stuff. > [~jmhsieh], FYI -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18228) HBCK improvements
[ https://issues.apache.org/jira/browse/HBASE-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18228: Component/s: hbck > HBCK improvements > - > > Key: HBASE-18228 > URL: https://issues.apache.org/jira/browse/HBASE-18228 > Project: HBase > Issue Type: Improvement > Components: hbck >Reporter: Lars Hofhansl >Priority: Critical > Fix For: 1.4.0 > > > We just had a prod issue and running HBCK the way we did actually causes more > problems. > In part HBCK did stuff we did not expect, in part we had little visibility > into what HBCK was doing, and in part the logging was confusing. > I'm proposing 2 improvements: > 1. A dry-run mode. Run, and just list what would have been done. > 2. An interactive mode. Run, and for each action request Y/N user input. So > that a user can opt-out of stuff. > [~jmhsieh], FYI -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18228) HBCK improvements
[ https://issues.apache.org/jira/browse/HBASE-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18228: Priority: Critical (was: Major) > HBCK improvements > - > > Key: HBASE-18228 > URL: https://issues.apache.org/jira/browse/HBASE-18228 > Project: HBase > Issue Type: Improvement >Reporter: Lars Hofhansl >Priority: Critical > > We just had a prod issue and running HBCK the way we did actually causes more > problems. > In part HBCK did stuff we did not expect, in part we had little visibility > into what HBCK was doing, and in part the logging was confusing. > I'm proposing 2 improvements: > 1. A dry-run mode. Run, and just list what would have been done. > 2. An interactive mode. Run, and for each action request Y/N user input. So > that a user can opt-out of stuff. > [~jmhsieh], FYI -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18228) HBCK improvements
[ https://issues.apache.org/jira/browse/HBASE-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18228: Issue Type: Improvement (was: Bug) > HBCK improvements > - > > Key: HBASE-18228 > URL: https://issues.apache.org/jira/browse/HBASE-18228 > Project: HBase > Issue Type: Improvement >Reporter: Lars Hofhansl > > We just had a prod issue and running HBCK the way we did actually causes more > problems. > In part HBCK did stuff we did not expect, in part we had little visibility > into what HBCK was doing, and in part the logging was confusing. > I'm proposing 2 improvements: > 1. A dry-run mode. Run, and just list what would have been done. > 2. An interactive mode. Run, and for each action request Y/N user input. So > that a user can opt-out of stuff. > [~jmhsieh], FYI -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18004) getRegionLocations needs to be called once in ScannerCallableWithReplicas#call()
[ https://issues.apache.org/jira/browse/HBASE-18004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huaxiang sun updated HBASE-18004: - Attachment: HBASE-18004.branch-1.001.patch > getRegionLocations needs to be called once in > ScannerCallableWithReplicas#call() > - > > Key: HBASE-18004 > URL: https://issues.apache.org/jira/browse/HBASE-18004 > Project: HBase > Issue Type: Improvement > Components: Client >Affects Versions: 2.0.0 >Reporter: huaxiang sun >Assignee: huaxiang sun >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-18004.branch-1.001.patch, > HBASE-18004-master-001.patch, HBASE-18004-master-002.patch > > > Look at this line, > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/ScannerCallableWithReplicas.java#L145 > It calls getRegionLocations() to get the primary region's locations. It's > usage is to figure out table's region replications. Since table's region > replication wont be changed until the table is disabled. It is safe to cache > this region replication. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17840) Update book
[
https://issues.apache.org/jira/browse/HBASE-17840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052439#comment-16052439
]
Hadoop QA commented on HBASE-17840:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 23s
{color} | {color:blue} Docker mode activated. {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} 6m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
46s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m 0s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
47s {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} hadoopcheck {color} | {color:green}
71m 7s {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-alpha3. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m 57s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 147m 51s
{color} | {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
55s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 252m 22s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestRegionReplicaFailover |
| | hadoop.hbase.regionserver.TestHRegion |
| | hadoop.hbase.regionserver.TestPerColumnFamilyFlush |
| | hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort |
| | hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster |
| Timed out junit tests |
org.apache.hadoop.hbase.replication.regionserver.TestRegionReplicaReplicationEndpoint
|
| | org.apache.hadoop.hbase.coprocessor.TestCoprocessorMetrics |
| | org.apache.hadoop.hbase.replication.regionserver.TestWALEntryStream |
| | org.apache.hadoop.hbase.replication.TestReplicationStatus |
| | org.apache.hadoop.hbase.regionserver.TestCompoundBloomFilter |
| | org.apache.hadoop.hbase.filter.TestFuzzyRowFilterEndToEnd |
| | org.apache.hadoop.hbase.replication.TestMasterReplication |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12873317/HBASE-17840.003.patch
|
| JIRA Issue | HBASE-17840 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux 97b242551f5e 4.8.3-std-1 #1 SMP Fri Oct 21 11:15:43 UTC 2016
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 / c7a64a8 |
| Default Java | 1.8.0_131 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/7206/artifact/patchprocess/patch-unit-root.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/7206/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7206/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7206/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Update book
> ---
>
> Key: HBASE-17840
> URL: https://issues.apache.org/jira/browse/HBASE-17840
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 3.0.0
>
> Attachments: HBASE-17840.001.patch, HBASE-17840.002.patch,
> HBASE-17840.003.patch
>
>
> Need to update the book to include the new
[jira] [Commented] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052432#comment-16052432
]
stack commented on HBASE-18227:
---
Lets see how this patch does... I think we should commit this first. This test
has been flakey a good while. You might have fixed the flakeyness [~uagashe]
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
>
> Key: HBASE-18227
> URL: https://issues.apache.org/jira/browse/HBASE-18227
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Attachments: HBASE-18227.master.001.patch
>
>
> When ExecuteProceduresRemoteCall in RemoteProcedureDispatcher is enabled the
> test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
> fails as it uses not supported call admin.closeRegion() to close a region.
> Disabling table later throws exception as one of the region is not online
> (already closed).
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> 2017-06-16 11:25:02,177 WARN [RSProcedureDispatcher-pool4-t6]
> procedure.RSProcedureDispatcher$AbstractRSRemoteCall(200): the request should
> be tried elsewhere instead; server=172.21.2.192,53652,1497637493318 try=0
> org.apache.hadoop.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:93)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:83)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:370)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:347)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.sendRequest(RSProcedureDispatcher.java:295)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:265)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:246)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.NotServingRegionException):
>
[jira] [Commented] (HBASE-16247) SparkSQL Avro serialization doesn't handle enums correctly
[ https://issues.apache.org/jira/browse/HBASE-16247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052427#comment-16052427 ] Jerry He commented on HBASE-16247: -- A solution for this JIRA is to add/excise more or all Avro types in the current Spark SQL Avro test cases. (The test coverage is not good now.) As long as the tests are in place, we can detect and prevent current or future incompatible handling if we upgrade Avro. Then we can close this JIRA. What do you think [~busbey]? > SparkSQL Avro serialization doesn't handle enums correctly > -- > > Key: HBASE-16247 > URL: https://issues.apache.org/jira/browse/HBASE-16247 > Project: HBase > Issue Type: Bug > Components: spark >Affects Versions: 2.0.0 >Reporter: Sean Busbey > Fix For: 2.0.0 > > > Avro's generic api expects GenericEnumSymbol as the runtime type for > instances of fields that are of Avro type ENUM. The Avro 1.7 libraries are > lax in some cases for handling this, but the 1.8 libraries are strict. We > should proactively fix our serialization. > (the lax serialization in 1.7 fails for some nested use in unions, see > AVRO-997 for details) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Liang updated HBASE-18229: - Description: See HBASE-18105 for related information, this jira will change the logic of Path 1 in splitProcedure, the execution path will be: *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> MasterRpcServices.splitRegion-> HMaster.splitRegion->AssignmentManager.submitProcedure* Master Will no longer as Rs and then Rs turn around to ask master to do the split operation. was: See HBASE-18105 for related information, this jira will change the logic of Path 1 in splitProcedure, the execution path will be: HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> MasterRpcServices.splitRegion-> HMaster.splitRegion->AssignmentManager.submitProcedure Master Will no longer as Rs and then Rs turn around to ask master to do the split operation. > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang > > See HBASE-18105 for related information, this jira will change the logic of > Path 1 in splitProcedure, the execution path will be: > *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> > MasterRpcServices.splitRegion-> > HMaster.splitRegion->AssignmentManager.submitProcedure* > Master Will no longer as Rs and then Rs turn around to ask master to do the > split operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Liang updated HBASE-18229: - Description: See HBASE-18105 for related information, this jira will change the logic of Path 1 in splitProcedure, the execution path will be: *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> MasterRpcServices.splitRegion -> HMaster.splitRegion-> AssignmentManager.submitProcedure* Master Will no longer as Rs and then Rs turn around to ask master to do the split operation. was: See HBASE-18105 for related information, this jira will change the logic of Path 1 in splitProcedure, the execution path will be: *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> MasterRpcServices.splitRegion-> HMaster.splitRegion->AssignmentManager.submitProcedure* Master Will no longer as Rs and then Rs turn around to ask master to do the split operation. > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang > > See HBASE-18105 for related information, this jira will change the logic of > Path 1 in splitProcedure, the execution path will be: > *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> > MasterRpcServices.splitRegion -> HMaster.splitRegion-> > AssignmentManager.submitProcedure* > Master Will no longer as Rs and then Rs turn around to ask master to do the > split operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Liang updated HBASE-18229: - Description: See HBASE-18105 for related information, this jira will change the logic of Path 1 in splitProcedure, the execution path will be: HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> MasterRpcServices.splitRegion-> HMaster.splitRegion->AssignmentManager.submitProcedure Master Will no longer as Rs and then Rs turn around to ask master to do the split operation. was:See HBASE-18105 for related information, this jira will change the logic of Path 1 in splitProcedure > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang > > See HBASE-18105 for related information, this jira will change the logic of > Path 1 in splitProcedure, the execution path will be: > HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> > MasterRpcServices.splitRegion-> > HMaster.splitRegion->AssignmentManager.submitProcedure > Master Will no longer as Rs and then Rs turn around to ask master to do the > split operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Liang updated HBASE-18229: - Description: See HBASE-18105 for related information, this jira will change the logic of Path 1 in splitProcedure > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang > > See HBASE-18105 for related information, this jira will change the logic of > Path 1 in splitProcedure -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Liang updated HBASE-18229: - Issue Type: Sub-task (was: New Feature) Parent: HBASE-14350 > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17840) Update book
[ https://issues.apache.org/jira/browse/HBASE-17840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052421#comment-16052421 ] Hudson commented on HBASE-17840: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3207 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3207/]) HBASE-17840 Update hbase book to space quotas on snapshots (elserj: rev 4dc805145b1d089a5c75d212bec922c1f6cf5fc5) * (edit) src/main/asciidoc/_chapters/ops_mgt.adoc > Update book > --- > > Key: HBASE-17840 > URL: https://issues.apache.org/jira/browse/HBASE-17840 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 3.0.0 > > Attachments: HBASE-17840.001.patch, HBASE-17840.002.patch, > HBASE-17840.003.patch > > > Need to update the book to include the new feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18229) create new Async Split API to embrace AM v2
Yi Liang created HBASE-18229: Summary: create new Async Split API to embrace AM v2 Key: HBASE-18229 URL: https://issues.apache.org/jira/browse/HBASE-18229 Project: HBase Issue Type: New Feature Components: proc-v2 Reporter: Yi Liang Assignee: Yi Liang -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18228) HBCK improvements
[ https://issues.apache.org/jira/browse/HBASE-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052415#comment-16052415 ] Lars Hofhansl commented on HBASE-18228: --- Somebody between my team and I will probably implement them. :) > HBCK improvements > - > > Key: HBASE-18228 > URL: https://issues.apache.org/jira/browse/HBASE-18228 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl > > We just had a prod issue and running HBCK the way we did actually causes more > problems. > In part HBCK did stuff we did not expect, in part we had little visibility > into what HBCK was doing, and in part the logging was confusing. > I'm proposing 2 improvements: > 1. A dry-run mode. Run, and just list what would have been done. > 2. An interactive mode. Run, and for each action request Y/N user input. So > that a user can opt-out of stuff. > [~jmhsieh], FYI -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-16247) SparkSQL Avro serialization doesn't handle enums correctly
[ https://issues.apache.org/jira/browse/HBASE-16247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-16247: Priority: Major (was: Critical) lowering priority while I figure out if this is currently a problem or not > SparkSQL Avro serialization doesn't handle enums correctly > -- > > Key: HBASE-16247 > URL: https://issues.apache.org/jira/browse/HBASE-16247 > Project: HBase > Issue Type: Bug > Components: spark >Affects Versions: 2.0.0 >Reporter: Sean Busbey > Fix For: 2.0.0 > > > Avro's generic api expects GenericEnumSymbol as the runtime type for > instances of fields that are of Avro type ENUM. The Avro 1.7 libraries are > lax in some cases for handling this, but the 1.8 libraries are strict. We > should proactively fix our serialization. > (the lax serialization in 1.7 fails for some nested use in unions, see > AVRO-997 for details) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052405#comment-16052405
]
Umesh Agashe commented on HBASE-18227:
--
Thanks [~stack]! for your suggestion to use unassign().
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
>
> Key: HBASE-18227
> URL: https://issues.apache.org/jira/browse/HBASE-18227
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Attachments: HBASE-18227.master.001.patch
>
>
> When ExecuteProceduresRemoteCall in RemoteProcedureDispatcher is enabled the
> test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
> fails as it uses not supported call admin.closeRegion() to close a region.
> Disabling table later throws exception as one of the region is not online
> (already closed).
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> 2017-06-16 11:25:02,177 WARN [RSProcedureDispatcher-pool4-t6]
> procedure.RSProcedureDispatcher$AbstractRSRemoteCall(200): the request should
> be tried elsewhere instead; server=172.21.2.192,53652,1497637493318 try=0
> org.apache.hadoop.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:93)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:83)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:370)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:347)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.sendRequest(RSProcedureDispatcher.java:295)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:265)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:246)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.NotServingRegionException):
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not
[jira] [Updated] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Umesh Agashe updated HBASE-18227:
-
Status: Patch Available (was: In Progress)
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
>
> Key: HBASE-18227
> URL: https://issues.apache.org/jira/browse/HBASE-18227
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Attachments: HBASE-18227.master.001.patch
>
>
> When ExecuteProceduresRemoteCall in RemoteProcedureDispatcher is enabled the
> test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
> fails as it uses not supported call admin.closeRegion() to close a region.
> Disabling table later throws exception as one of the region is not online
> (already closed).
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> 2017-06-16 11:25:02,177 WARN [RSProcedureDispatcher-pool4-t6]
> procedure.RSProcedureDispatcher$AbstractRSRemoteCall(200): the request should
> be tried elsewhere instead; server=172.21.2.192,53652,1497637493318 try=0
> org.apache.hadoop.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:93)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:83)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:370)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:347)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.sendRequest(RSProcedureDispatcher.java:295)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:265)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:246)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.NotServingRegionException):
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
>
[jira] [Updated] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Umesh Agashe updated HBASE-18227:
-
Attachment: HBASE-18227.master.001.patch
Calling closeRegion() directly on remote server is not supported post-AMv2.
Calling unassign() on master
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
>
> Key: HBASE-18227
> URL: https://issues.apache.org/jira/browse/HBASE-18227
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Attachments: HBASE-18227.master.001.patch
>
>
> When ExecuteProceduresRemoteCall in RemoteProcedureDispatcher is enabled the
> test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
> fails as it uses not supported call admin.closeRegion() to close a region.
> Disabling table later throws exception as one of the region is not online
> (already closed).
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> 2017-06-16 11:25:02,177 WARN [RSProcedureDispatcher-pool4-t6]
> procedure.RSProcedureDispatcher$AbstractRSRemoteCall(200): the request should
> be tried elsewhere instead; server=172.21.2.192,53652,1497637493318 try=0
> org.apache.hadoop.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:93)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:83)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:370)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:347)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.sendRequest(RSProcedureDispatcher.java:295)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:265)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:246)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.NotServingRegionException):
> org.apache.hadoop.hbase.NotServingRegionException: The region
>
[jira] [Work started] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-18227 started by Umesh Agashe.
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
>
> Key: HBASE-18227
> URL: https://issues.apache.org/jira/browse/HBASE-18227
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
>
> When ExecuteProceduresRemoteCall in RemoteProcedureDispatcher is enabled the
> test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
> fails as it uses not supported call admin.closeRegion() to close a region.
> Disabling table later throws exception as one of the region is not online
> (already closed).
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> 2017-06-16 11:25:02,177 WARN [RSProcedureDispatcher-pool4-t6]
> procedure.RSProcedureDispatcher$AbstractRSRemoteCall(200): the request should
> be tried elsewhere instead; server=172.21.2.192,53652,1497637493318 try=0
> org.apache.hadoop.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:93)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:83)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:370)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:347)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.sendRequest(RSProcedureDispatcher.java:295)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:265)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:246)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.NotServingRegionException):
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
>
[jira] [Commented] (HBASE-18228) HBCK improvements
[ https://issues.apache.org/jira/browse/HBASE-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052400#comment-16052400 ] Jonathan Hsieh commented on HBASE-18228: These sound like fine ideas. I think we'd want to limit the scope of this to Hbase 1.x since Hbase 2.x will likely rewrite hbck for its particular problems. [~larsh], do you plan on writing these improvements? > HBCK improvements > - > > Key: HBASE-18228 > URL: https://issues.apache.org/jira/browse/HBASE-18228 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl > > We just had a prod issue and running HBCK the way we did actually causes more > problems. > In part HBCK did stuff we did not expect, in part we had little visibility > into what HBCK was doing, and in part the logging was confusing. > I'm proposing 2 improvements: > 1. A dry-run mode. Run, and just list what would have been done. > 2. An interactive mode. Run, and for each action request Y/N user input. So > that a user can opt-out of stuff. > [~jmhsieh], FYI -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18218) List replication peers for the cluster
[ https://issues.apache.org/jira/browse/HBASE-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052399#comment-16052399 ] Ali edited comment on HBASE-18218 at 6/16/17 9:14 PM: -- v2 patch for branch-1 attached as well was (Author: aky): v2 patch for branch-1 > List replication peers for the cluster > -- > > Key: HBASE-18218 > URL: https://issues.apache.org/jira/browse/HBASE-18218 > Project: HBase > Issue Type: New Feature >Reporter: Ali >Assignee: Ali > Attachments: HBASE-18218.v1.branch-1.2.patch, > HBASE-18218.v2.branch-1.patch, HBASE-18218.v2.master.patch, screenshot-1.png, > screenshot-2.png > > > HBase Master page that listed all the replication peers for a cluster, with > their associated metadata -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18218) List replication peers for the cluster
[ https://issues.apache.org/jira/browse/HBASE-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali updated HBASE-18218: Attachment: HBASE-18218.v2.branch-1.patch v2 patch for branch-1 > List replication peers for the cluster > -- > > Key: HBASE-18218 > URL: https://issues.apache.org/jira/browse/HBASE-18218 > Project: HBase > Issue Type: New Feature >Reporter: Ali >Assignee: Ali > Attachments: HBASE-18218.v1.branch-1.2.patch, > HBASE-18218.v2.branch-1.patch, HBASE-18218.v2.master.patch, screenshot-1.png, > screenshot-2.png > > > HBase Master page that listed all the replication peers for a cluster, with > their associated metadata -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18228) HBCK improvements
Lars Hofhansl created HBASE-18228: - Summary: HBCK improvements Key: HBASE-18228 URL: https://issues.apache.org/jira/browse/HBASE-18228 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl We just had a prod issue and running HBCK the way we did actually causes more problems. In part HBCK did stuff we did not expect, in part we had little visibility into what HBCK was doing, and in part the logging was confusing. I'm proposing 2 improvements: 1. A dry-run mode. Run, and just list what would have been done. 2. An interactive mode. Run, and for each action request Y/N user input. So that a user can opt-out of stuff. [~jmhsieh], FYI -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16242) Upgrade Avro
[ https://issues.apache.org/jira/browse/HBASE-16242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052379#comment-16052379 ] Sean Busbey commented on HBASE-16242: - Yeah that sounds reasonable to me. We can work out the 1.8 upgrade once Hadoop 3 is settled. > Upgrade Avro > > > Key: HBASE-16242 > URL: https://issues.apache.org/jira/browse/HBASE-16242 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Ben McCann > > I'd like to see Avro upgraded to 1.8.1 or at the very least 1.7.7 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18227) [AMv2] Fix test hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
[
https://issues.apache.org/jira/browse/HBASE-18227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Umesh Agashe reassigned HBASE-18227:
Assignee: Umesh Agashe
> [AMv2] Fix test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
>
>
> Key: HBASE-18227
> URL: https://issues.apache.org/jira/browse/HBASE-18227
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0-alpha-1
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
>
> When ExecuteProceduresRemoteCall in RemoteProcedureDispatcher is enabled the
> test
> hbase.coprocessor.TestCoprocessorMetrics#testRegionObserverAfterRegionClosed
> fails as it uses not supported call admin.closeRegion() to close a region.
> Disabling table later throws exception as one of the region is not online
> (already closed).
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> 2017-06-16 11:25:02,177 WARN [RSProcedureDispatcher-pool4-t6]
> procedure.RSProcedureDispatcher$AbstractRSRemoteCall(200): the request should
> be tried elsewhere instead; server=172.21.2.192,53652,1497637493318 try=0
> org.apache.hadoop.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.closeRegion(RSRpcServices.java:1485)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.executeProcedures(RSRpcServices.java:3430)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:28757)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:278)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:258)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:93)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:83)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:370)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:347)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.sendRequest(RSProcedureDispatcher.java:295)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:265)
> at
> org.apache.hadoop.hbase.master.procedure.RSProcedureDispatcher$ExecuteProceduresRemoteCall.call(RSProcedureDispatcher.java:246)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.NotServingRegionException):
> org.apache.hadoop.hbase.NotServingRegionException: The region
> d8c770379823cbe6cdc517327024b128 is not online, and is not opening.
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:3111)
> at
>
[jira] [Updated] (HBASE-18218) List replication peers for the cluster
[ https://issues.apache.org/jira/browse/HBASE-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali updated HBASE-18218: Status: Patch Available (was: Open) v2 master patch includes configuration data, status (enabled/disabled data) > List replication peers for the cluster > -- > > Key: HBASE-18218 > URL: https://issues.apache.org/jira/browse/HBASE-18218 > Project: HBase > Issue Type: New Feature >Reporter: Ali >Assignee: Ali > Attachments: HBASE-18218.v1.branch-1.2.patch, > HBASE-18218.v2.master.patch, screenshot-1.png, screenshot-2.png > > > HBase Master page that listed all the replication peers for a cluster, with > their associated metadata -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18218) List replication peers for the cluster
[ https://issues.apache.org/jira/browse/HBASE-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali updated HBASE-18218: Attachment: screenshot-2.png > List replication peers for the cluster > -- > > Key: HBASE-18218 > URL: https://issues.apache.org/jira/browse/HBASE-18218 > Project: HBase > Issue Type: New Feature >Reporter: Ali >Assignee: Ali > Attachments: HBASE-18218.v1.branch-1.2.patch, > HBASE-18218.v2.master.patch, screenshot-1.png, screenshot-2.png > > > HBase Master page that listed all the replication peers for a cluster, with > their associated metadata -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18218) List replication peers for the cluster
[ https://issues.apache.org/jira/browse/HBASE-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali updated HBASE-18218: Attachment: (was: Screen Shot 2017-06-15 at 10.28.08 PM.png) > List replication peers for the cluster > -- > > Key: HBASE-18218 > URL: https://issues.apache.org/jira/browse/HBASE-18218 > Project: HBase > Issue Type: New Feature >Reporter: Ali >Assignee: Ali > Attachments: HBASE-18218.v1.branch-1.2.patch, > HBASE-18218.v2.master.patch, screenshot-1.png, screenshot-2.png > > > HBase Master page that listed all the replication peers for a cluster, with > their associated metadata -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18218) List replication peers for the cluster
[ https://issues.apache.org/jira/browse/HBASE-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali updated HBASE-18218: Attachment: Screen Shot 2017-06-15 at 10.28.08 PM.png > List replication peers for the cluster > -- > > Key: HBASE-18218 > URL: https://issues.apache.org/jira/browse/HBASE-18218 > Project: HBase > Issue Type: New Feature >Reporter: Ali >Assignee: Ali > Attachments: HBASE-18218.v1.branch-1.2.patch, > HBASE-18218.v2.master.patch, screenshot-1.png, Screen Shot 2017-06-15 at > 10.28.08 PM.png > > > HBase Master page that listed all the replication peers for a cluster, with > their associated metadata -- This message was sent by Atlassian JIRA (v6.4.14#64029)
