[jira] [Commented] (HBASE-13882) Fix RegionSplitPolicy section in HBase book
[
https://issues.apache.org/jira/browse/HBASE-13882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873501#comment-15873501
]
Hadoop QA commented on HBASE-13882:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 17s
{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
22s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
31s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 26s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
29s {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}
30m 31s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 19s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 144m 34s
{color} | {color:red} root 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} 190m 28s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.thrift.TestThriftServerCmdLine |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12853436/HBASE-13882.master.001.patch
|
| JIRA Issue | HBASE-13882 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux dd075e6ea36a 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 350904e |
| Default Java | 1.8.0_121 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/5765/artifact/patchprocess/patch-unit-root.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/5765/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/5765/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/5765/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Fix RegionSplitPolicy section in HBase book
>
>
> Key: HBASE-13882
> URL: https://issues.apache.org/jira/browse/HBASE-13882
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Vladimir Rodionov
>Assignee: Jan Hentschel
>Priority: Trivial
> Attachments: HBASE-13882.master.001.patch
>
>
> 65.4.1. Custom Split Policies
> The section starts with the following statement:
> {quote}
> ou can override the default split policy using a custom
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend
> HBase’s default split policy: IncreasingToUpperBoundRegionSplitPolicy.
> {quote}
> There is typo above as well.
> Then if we scroll down a little bit:
> {quote}
> The default split policy can be overwritten using a custom
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend
> HBase’s default split policy: ConstantSizeRegionSplitPolicy.
> {quote}
> The link:
> http://hbase.apache.org/book.html#_custom_split_policies
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-13074) Clean up old code around "hbase.master.lease.thread.wakefrequency" as it is not used anymore..
[
https://issues.apache.org/jira/browse/HBASE-13074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873500#comment-15873500
]
Hadoop QA commented on HBASE-13074:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s
{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 7 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} 3m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 21s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
7s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 25s
{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} 2m
33s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 23s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 23s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
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} xml {color} | {color:green} 0m 6s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
29m 40s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
28s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 13s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 117m 50s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 1m 57s {color}
| {color:red} hbase-thrift in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 54s
{color} | {color:green} hbase-rest in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 35s
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
52s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 189m 28s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.thrift.TestThriftServerCmdLine |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12853438/HBASE-13074.master.001.patch
|
| JIRA Issue | HBASE-13074 |
| Optional Tests | asflicense unit xml javac javadoc findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 675caa44b124 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-17561) table status page should escape values that may contain arbitrary characters.
[
https://issues.apache.org/jira/browse/HBASE-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873492#comment-15873492
]
Hudson commented on HBASE-17561:
SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2530 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/2530/])
HBASE-17561 table status page should escape values that may contain (busbey:
rev 350904e90f33dc31f40ab9560848e37745b9c2c5)
* (edit) hbase-server/src/main/resources/hbase-webapps/master/table.jsp
> table status page should escape values that may contain arbitrary characters.
> -
>
> Key: HBASE-17561
> URL: https://issues.apache.org/jira/browse/HBASE-17561
> Project: HBase
> Issue Type: Sub-task
> Components: master, UI
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Attachments: HBASE-17561.0.patch
>
>
> We write out table names to an html document without escaping html entities
> e.g. in this case it even comes directly from the request
> {code}
>
> <% if ( !readOnly && action != null ) { %>
> HBase Master: <%= master.getServerName() %>
> <% } else { %>
> Table: <%= fqtn %>
> <% } %>
> {code}
> in
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/resources/hbase-webapps/master/table.jsp
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17460) enable_table_replication can not perform cyclic replication of a table
[ https://issues.apache.org/jira/browse/HBASE-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873387#comment-15873387 ] Ted Yu commented on HBASE-17460: [~nitin.ve...@gmail.com]: Do you have time to compose patch for branch-1 ? > enable_table_replication can not perform cyclic replication of a table > -- > > Key: HBASE-17460 > URL: https://issues.apache.org/jira/browse/HBASE-17460 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: NITIN VERMA >Assignee: NITIN VERMA > Labels: incompatibleChange, replication > Fix For: 2.0.0 > > Attachments: 17460.branch-1.v3.txt, 17460.v5.txt, HBASE-17460.patch, > HBASE-17460_v2.patch, HBASE-17460_v3.patch, HBASE-17460_v4.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > The enable_table_replication operation is broken for cyclic replication of > HBase table as we compare all the properties of column families (including > REPLICATION_SCOPE). > Below is exactly what happens: > 1. Running "enable_table_replication 'table1' " opeartion on first cluster > will set the REPLICATION_SCOPE of all column families to peer id '1'. This > will also create a table on second cluster where REPLICATION_SCOPE is still > set to peer id '0'. > 2. Now when we run "enable_table_replication 'table1'" on second cluster, we > compare all the properties of table (including REPLICATION_SCOPE_, which > obviously is different now. > I am proposing a fix for this issue where we should avoid comparing > REPLICATION_SCOPE inside HColumnDescriotor::compareTo() method, especially > when replication is not already enabled on the desired table. > I have made that change and it is working. I will submit the patch soon. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17460) enable_table_replication can not perform cyclic replication of a table
[ https://issues.apache.org/jira/browse/HBASE-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873366#comment-15873366 ] NITIN VERMA commented on HBASE-17460: - Hi [~tedyu], sorry, I couldn't get back to test sooner. I was out of office. Your change to fix the test (testEnableReplicationWhenSlaveClusterDoesntHaveTable) looks fine to me. > enable_table_replication can not perform cyclic replication of a table > -- > > Key: HBASE-17460 > URL: https://issues.apache.org/jira/browse/HBASE-17460 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: NITIN VERMA >Assignee: NITIN VERMA > Labels: incompatibleChange, replication > Fix For: 2.0.0 > > Attachments: 17460.branch-1.v3.txt, 17460.v5.txt, HBASE-17460.patch, > HBASE-17460_v2.patch, HBASE-17460_v3.patch, HBASE-17460_v4.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > The enable_table_replication operation is broken for cyclic replication of > HBase table as we compare all the properties of column families (including > REPLICATION_SCOPE). > Below is exactly what happens: > 1. Running "enable_table_replication 'table1' " opeartion on first cluster > will set the REPLICATION_SCOPE of all column families to peer id '1'. This > will also create a table on second cluster where REPLICATION_SCOPE is still > set to peer id '0'. > 2. Now when we run "enable_table_replication 'table1'" on second cluster, we > compare all the properties of table (including REPLICATION_SCOPE_, which > obviously is different now. > I am proposing a fix for this issue where we should avoid comparing > REPLICATION_SCOPE inside HColumnDescriotor::compareTo() method, especially > when replication is not already enabled on the desired table. > I have made that change and it is working. I will submit the patch soon. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-3944) Remove the overused hbase.server.thread.wakefrequency and replace with multiple configs. specific to context
[ https://issues.apache.org/jira/browse/HBASE-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873359#comment-15873359 ] Jan Hentschel commented on HBASE-3944: -- This seems to be part of HBASE-13074 which removes the remaining usages of hbase.server.thread.wakefrequency. > Remove the overused hbase.server.thread.wakefrequency and replace with > multiple configs. specific to context > > > Key: HBASE-3944 > URL: https://issues.apache.org/jira/browse/HBASE-3944 > Project: HBase > Issue Type: Bug >Reporter: stack > > From LarsG up on list: > implicitly triggers the above check. Also this > > > > > > hbase.server.thread.wakefrequency > > 1 > > Time to sleep in between searches for work (in > > milliseconds). > > Used as sleep interval by service threads such as log roller. > > > > > > > > which is used in this scenario to trigger the check when there is no > > event (put/delete etc.) is quite ambiguous and warrants for a better > > explanation. No? > The above config. is overdone. Remove it and make multiple individual, > context-specific configs in its place. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-13074) Clean up old code around "hbase.master.lease.thread.wakefrequency" as it is not used anymore..
[ https://issues.apache.org/jira/browse/HBASE-13074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Hentschel updated HBASE-13074: -- Status: Patch Available (was: In Progress) > Clean up old code around "hbase.master.lease.thread.wakefrequency" as it is > not used anymore.. > -- > > Key: HBASE-13074 > URL: https://issues.apache.org/jira/browse/HBASE-13074 > Project: HBase > Issue Type: Task > Components: wal >Reporter: Sunil >Assignee: Jan Hentschel >Priority: Trivial > Attachments: HBASE-13074.master.001.patch > > > While checking for configs to tweak, I ran into > hbase.master.lease.thread.wakefrequency, but it has been deprecated. There > are however still references of it in a few tests classes so just cleaning it > up.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-13074) Clean up old code around "hbase.master.lease.thread.wakefrequency" as it is not used anymore..
[ https://issues.apache.org/jira/browse/HBASE-13074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Hentschel updated HBASE-13074: -- Attachment: HBASE-13074.master.001.patch > Clean up old code around "hbase.master.lease.thread.wakefrequency" as it is > not used anymore.. > -- > > Key: HBASE-13074 > URL: https://issues.apache.org/jira/browse/HBASE-13074 > Project: HBase > Issue Type: Task > Components: wal >Reporter: Sunil >Assignee: Jan Hentschel >Priority: Trivial > Attachments: HBASE-13074.master.001.patch > > > While checking for configs to tweak, I ran into > hbase.master.lease.thread.wakefrequency, but it has been deprecated. There > are however still references of it in a few tests classes so just cleaning it > up.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (HBASE-13074) Clean up old code around "hbase.master.lease.thread.wakefrequency" as it is not used anymore..
[ https://issues.apache.org/jira/browse/HBASE-13074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Hentschel reassigned HBASE-13074: - Assignee: Jan Hentschel > Clean up old code around "hbase.master.lease.thread.wakefrequency" as it is > not used anymore.. > -- > > Key: HBASE-13074 > URL: https://issues.apache.org/jira/browse/HBASE-13074 > Project: HBase > Issue Type: Task > Components: wal >Reporter: Sunil >Assignee: Jan Hentschel >Priority: Trivial > > While checking for configs to tweak, I ran into > hbase.master.lease.thread.wakefrequency, but it has been deprecated. There > are however still references of it in a few tests classes so just cleaning it > up.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Work started] (HBASE-13074) Clean up old code around "hbase.master.lease.thread.wakefrequency" as it is not used anymore..
[ https://issues.apache.org/jira/browse/HBASE-13074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-13074 started by Jan Hentschel. - > Clean up old code around "hbase.master.lease.thread.wakefrequency" as it is > not used anymore.. > -- > > Key: HBASE-13074 > URL: https://issues.apache.org/jira/browse/HBASE-13074 > Project: HBase > Issue Type: Task > Components: wal >Reporter: Sunil >Assignee: Jan Hentschel >Priority: Trivial > > While checking for configs to tweak, I ran into > hbase.master.lease.thread.wakefrequency, but it has been deprecated. There > are however still references of it in a few tests classes so just cleaning it > up.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17460) enable_table_replication can not perform cyclic replication of a table
[ https://issues.apache.org/jira/browse/HBASE-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873348#comment-15873348 ] Ted Yu commented on HBASE-17460: bq. seems like a flag would be better. Yes. bq. there is some way to do the same operation once this change is in place Can you elaborate a bit more on how the same operation can be performed with patch in place (if no flag is introduced)? Thanks > enable_table_replication can not perform cyclic replication of a table > -- > > Key: HBASE-17460 > URL: https://issues.apache.org/jira/browse/HBASE-17460 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: NITIN VERMA >Assignee: NITIN VERMA > Labels: incompatibleChange, replication > Fix For: 2.0.0 > > Attachments: 17460.branch-1.v3.txt, 17460.v5.txt, HBASE-17460.patch, > HBASE-17460_v2.patch, HBASE-17460_v3.patch, HBASE-17460_v4.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > The enable_table_replication operation is broken for cyclic replication of > HBase table as we compare all the properties of column families (including > REPLICATION_SCOPE). > Below is exactly what happens: > 1. Running "enable_table_replication 'table1' " opeartion on first cluster > will set the REPLICATION_SCOPE of all column families to peer id '1'. This > will also create a table on second cluster where REPLICATION_SCOPE is still > set to peer id '0'. > 2. Now when we run "enable_table_replication 'table1'" on second cluster, we > compare all the properties of table (including REPLICATION_SCOPE_, which > obviously is different now. > I am proposing a fix for this issue where we should avoid comparing > REPLICATION_SCOPE inside HColumnDescriotor::compareTo() method, especially > when replication is not already enabled on the desired table. > I have made that change and it is working. I will submit the patch soon. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17460) enable_table_replication can not perform cyclic replication of a table
[ https://issues.apache.org/jira/browse/HBASE-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-17460: --- Release Note: Fixing enable_table_replication for cyclic replication. Previously if the replication is enabled , user executes the enable table replication command again and If table descriptor matches, it will check the replication scope for each column family and if any of the column family scope is not enabled, it will enable it. Otherwise nothing is done and final result is success. But as per the patch, it will throw exception if replication is already enabled for some column family. was:Fixing enable_table_replication for cyclic replication. > enable_table_replication can not perform cyclic replication of a table > -- > > Key: HBASE-17460 > URL: https://issues.apache.org/jira/browse/HBASE-17460 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: NITIN VERMA >Assignee: NITIN VERMA > Labels: incompatibleChange, replication > Fix For: 2.0.0 > > Attachments: 17460.branch-1.v3.txt, 17460.v5.txt, HBASE-17460.patch, > HBASE-17460_v2.patch, HBASE-17460_v3.patch, HBASE-17460_v4.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > The enable_table_replication operation is broken for cyclic replication of > HBase table as we compare all the properties of column families (including > REPLICATION_SCOPE). > Below is exactly what happens: > 1. Running "enable_table_replication 'table1' " opeartion on first cluster > will set the REPLICATION_SCOPE of all column families to peer id '1'. This > will also create a table on second cluster where REPLICATION_SCOPE is still > set to peer id '0'. > 2. Now when we run "enable_table_replication 'table1'" on second cluster, we > compare all the properties of table (including REPLICATION_SCOPE_, which > obviously is different now. > I am proposing a fix for this issue where we should avoid comparing > REPLICATION_SCOPE inside HColumnDescriotor::compareTo() method, especially > when replication is not already enabled on the desired table. > I have made that change and it is working. I will submit the patch soon. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-13882) Fix RegionSplitPolicy section in HBase book
[
https://issues.apache.org/jira/browse/HBASE-13882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel updated HBASE-13882:
--
Status: Patch Available (was: In Progress)
> Fix RegionSplitPolicy section in HBase book
>
>
> Key: HBASE-13882
> URL: https://issues.apache.org/jira/browse/HBASE-13882
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Vladimir Rodionov
>Assignee: Jan Hentschel
>Priority: Trivial
> Attachments: HBASE-13882.master.001.patch
>
>
> 65.4.1. Custom Split Policies
> The section starts with the following statement:
> {quote}
> ou can override the default split policy using a custom
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend
> HBase’s default split policy: IncreasingToUpperBoundRegionSplitPolicy.
> {quote}
> There is typo above as well.
> Then if we scroll down a little bit:
> {quote}
> The default split policy can be overwritten using a custom
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend
> HBase’s default split policy: ConstantSizeRegionSplitPolicy.
> {quote}
> The link:
> http://hbase.apache.org/book.html#_custom_split_policies
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-13882) Fix RegionSplitPolicy section in HBase book
[
https://issues.apache.org/jira/browse/HBASE-13882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel updated HBASE-13882:
--
Attachment: HBASE-13882.master.001.patch
> Fix RegionSplitPolicy section in HBase book
>
>
> Key: HBASE-13882
> URL: https://issues.apache.org/jira/browse/HBASE-13882
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Vladimir Rodionov
>Assignee: Jan Hentschel
>Priority: Trivial
> Attachments: HBASE-13882.master.001.patch
>
>
> 65.4.1. Custom Split Policies
> The section starts with the following statement:
> {quote}
> ou can override the default split policy using a custom
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend
> HBase’s default split policy: IncreasingToUpperBoundRegionSplitPolicy.
> {quote}
> There is typo above as well.
> Then if we scroll down a little bit:
> {quote}
> The default split policy can be overwritten using a custom
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend
> HBase’s default split policy: ConstantSizeRegionSplitPolicy.
> {quote}
> The link:
> http://hbase.apache.org/book.html#_custom_split_policies
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (HBASE-13882) Fix RegionSplitPolicy section in HBase book
[
https://issues.apache.org/jira/browse/HBASE-13882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel reassigned HBASE-13882:
-
Assignee: Jan Hentschel
> Fix RegionSplitPolicy section in HBase book
>
>
> Key: HBASE-13882
> URL: https://issues.apache.org/jira/browse/HBASE-13882
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Vladimir Rodionov
>Assignee: Jan Hentschel
>Priority: Trivial
>
> 65.4.1. Custom Split Policies
> The section starts with the following statement:
> {quote}
> ou can override the default split policy using a custom
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend
> HBase’s default split policy: IncreasingToUpperBoundRegionSplitPolicy.
> {quote}
> There is typo above as well.
> Then if we scroll down a little bit:
> {quote}
> The default split policy can be overwritten using a custom
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend
> HBase’s default split policy: ConstantSizeRegionSplitPolicy.
> {quote}
> The link:
> http://hbase.apache.org/book.html#_custom_split_policies
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Work started] (HBASE-13882) Fix RegionSplitPolicy section in HBase book
[
https://issues.apache.org/jira/browse/HBASE-13882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-13882 started by Jan Hentschel.
-
> Fix RegionSplitPolicy section in HBase book
>
>
> Key: HBASE-13882
> URL: https://issues.apache.org/jira/browse/HBASE-13882
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Vladimir Rodionov
>Assignee: Jan Hentschel
>Priority: Trivial
>
> 65.4.1. Custom Split Policies
> The section starts with the following statement:
> {quote}
> ou can override the default split policy using a custom
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend
> HBase’s default split policy: IncreasingToUpperBoundRegionSplitPolicy.
> {quote}
> There is typo above as well.
> Then if we scroll down a little bit:
> {quote}
> The default split policy can be overwritten using a custom
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend
> HBase’s default split policy: ConstantSizeRegionSplitPolicy.
> {quote}
> The link:
> http://hbase.apache.org/book.html#_custom_split_policies
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17460) enable_table_replication can not perform cyclic replication of a table
[
https://issues.apache.org/jira/browse/HBASE-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873340#comment-15873340
]
Sean Busbey commented on HBASE-17460:
-
I thought the incompatible part of the change was that previously if you had a
table where replication was on for some column families and off for others then
we'd enable it for any where it was off, and now we fail.
{quote}
This patch will have one incompatible behavior change for enable table
replication API.
As per the earlier behavior, If the replication is enabled , user executes the
enable table replication command again and If table descriptor matches , It
will check the replication scope for each column family and if any of the
column family scope is not enabled, it will enable it. otherwise it will do
nothing and final result is success. But as per the patch, it will throw
exception if replication is already enabled.
{quote}
Is the above from [~Bhupendra] not the case, [~yuzhih...@gmail.com]? If it does
correctly describe the current behavior, I'm fine with a breaking change so
long as 1) we call out the breakage in a release note (the current release note
doesn't sufficiently explain things) and 2) we ensure there is some way to do
the same operation once this change is in place (and also explain such in the
release note). Note that these two things are already needed, since you've
pushed this change to master again.
If we're going use a config to get the old config, that seems a bit heavy for
changing how one invokes a shell command. we'd need to call it out in the help
for the shell command and then I guess we'd expect folks to relaunch the shell
with the modified config? seems like a flag would be better. or perhaps we need
some direct way to say "ensure the replication scope for all the column
families in this table is enabled".
> enable_table_replication can not perform cyclic replication of a table
> --
>
> Key: HBASE-17460
> URL: https://issues.apache.org/jira/browse/HBASE-17460
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: NITIN VERMA
>Assignee: NITIN VERMA
> Labels: incompatibleChange, replication
> Fix For: 2.0.0
>
> Attachments: 17460.branch-1.v3.txt, 17460.v5.txt, HBASE-17460.patch,
> HBASE-17460_v2.patch, HBASE-17460_v3.patch, HBASE-17460_v4.patch
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> The enable_table_replication operation is broken for cyclic replication of
> HBase table as we compare all the properties of column families (including
> REPLICATION_SCOPE).
> Below is exactly what happens:
> 1. Running "enable_table_replication 'table1' " opeartion on first cluster
> will set the REPLICATION_SCOPE of all column families to peer id '1'. This
> will also create a table on second cluster where REPLICATION_SCOPE is still
> set to peer id '0'.
> 2. Now when we run "enable_table_replication 'table1'" on second cluster, we
> compare all the properties of table (including REPLICATION_SCOPE_, which
> obviously is different now.
> I am proposing a fix for this issue where we should avoid comparing
> REPLICATION_SCOPE inside HColumnDescriotor::compareTo() method, especially
> when replication is not already enabled on the desired table.
> I have made that change and it is working. I will submit the patch soon.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17657) TestZKAsyncRegistry is flaky
[
https://issues.apache.org/jira/browse/HBASE-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873298#comment-15873298
]
Ted Yu commented on HBASE-17657:
Looking at ZKAsyncRegistry#getMetaRegionLocation() (where the WARN message from
test output came from) :
{code}
if (stateAndServerName.getFirst() != RegionState.State.OPEN) {
LOG.warn("Meta region for replica " + replicaId + " is in state "
+ stateAndServerName.getFirst());
locs[replicaId] = null;
{code}
Meaning, when location for any replica is not known, null would be returned.
This was what happened during failed test (breakpoint on the above line in
Eclipse isn't hit for successful test run).
This means, the test should exercise getMetaRegionLocation() more than once to
deal with the situation where location for some replica is not known
temporarily.
> TestZKAsyncRegistry is flaky
> -
>
> Key: HBASE-17657
> URL: https://issues.apache.org/jira/browse/HBASE-17657
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17657.v1.txt
>
>
> TestZKAsyncRegistry showed up in failed tests several times.
> On
> https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html
> , TestZKAsyncRegistry is reported flaky 33% of the time.
> e.g.
> https://builds.apache.org/job/PreCommit-HBASE-Build/5708/testReport/org.apache.hadoop.hbase.client/TestZKAsyncRegistry/test/
> Toward the end of test output:
> {code}
> 2017-02-14 20:23:20,779 WARN [main-EventThread] client.ZKAsyncRegistry(198):
> Meta region for replica 2 is in state PENDING_OPEN
> 2017-02-14 20:23:20,800 INFO [98410feec74d:45445.activeMasterManager]
> hbase.MetaTableAccessor(1767): Updated table hbase:meta state to ENABLED in
> META
> 2017-02-14 20:23:20,804 DEBUG [PostOpenDeployTasks:534574363]
> regionserver.HRegionServer(2034): Finished post open deploy task for
> hbase:meta,,1_0001.534574363
> 2017-02-14 20:23:20,811 DEBUG [RS_OPEN_META-98410feec74d:50745-0]
> handler.OpenRegionHandler(126): Opened hbase:meta,,1_0001.534574363 on
> 98410feec74d,50745,1487103793930
> {code}
> Looks like some replica of the hbase:meta table might not have finished
> opening by the time the test asserted region location not being null.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors
[
https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873216#comment-15873216
]
Hadoop QA commented on HBASE-17312:
---
| (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:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 52 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 25s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
7s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 49s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
54s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 39s
{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} 5m
7s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 51s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m 51s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
50s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
50s {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 11s {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-alpha2. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 44s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 13s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 94m 7s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 1m 50s {color}
| {color:red} hbase-thrift in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 42s
{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 3m 57s {color}
| {color:red} hbase-endpoint in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 20s
{color} | {color:green} hbase-it in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 23s
{color} | {color:green} hbase-examples in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 121m 5s {color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
47s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black}
[jira] [Comment Edited] (HBASE-17657) TestZKAsyncRegistry is flaky
[
https://issues.apache.org/jira/browse/HBASE-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873202#comment-15873202
]
Ted Yu edited comment on HBASE-17657 at 2/18/17 3:12 PM:
-
bq. to detect if all the replicas for meta region is ready
TEST_UTIL.waitUntilAllRegionsAssigned(TableName.META_TABLE_NAME) does that.
But this test is about AsyncMetaRegionLocator. I searched code base. This is
the only test which references AsyncMetaRegionLocator#getMetaRegionLocation() /
AsyncRegistry#getMetaRegionLocation().
[~Apache9]:
Do you have suggestion how meta region location should be retrieved from
AsyncMetaRegionLocator ?
was (Author: yuzhih...@gmail.com):
bq. to detect if all the replicas for meta region is ready
TEST_UTIL.waitUntilAllRegionsAssigned(TableName.META_TABLE_NAME) does that.
But this test is about AsyncMetaRegionLocator. I searched code base. This is
the only test which references AsyncMetaRegionLocator#getMetaRegionLocation().
[~Apache9]:
Do you have suggestion how meta region location should be retrieved from
AsyncMetaRegionLocator ?
> TestZKAsyncRegistry is flaky
> -
>
> Key: HBASE-17657
> URL: https://issues.apache.org/jira/browse/HBASE-17657
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17657.v1.txt
>
>
> TestZKAsyncRegistry showed up in failed tests several times.
> On
> https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html
> , TestZKAsyncRegistry is reported flaky 33% of the time.
> e.g.
> https://builds.apache.org/job/PreCommit-HBASE-Build/5708/testReport/org.apache.hadoop.hbase.client/TestZKAsyncRegistry/test/
> Toward the end of test output:
> {code}
> 2017-02-14 20:23:20,779 WARN [main-EventThread] client.ZKAsyncRegistry(198):
> Meta region for replica 2 is in state PENDING_OPEN
> 2017-02-14 20:23:20,800 INFO [98410feec74d:45445.activeMasterManager]
> hbase.MetaTableAccessor(1767): Updated table hbase:meta state to ENABLED in
> META
> 2017-02-14 20:23:20,804 DEBUG [PostOpenDeployTasks:534574363]
> regionserver.HRegionServer(2034): Finished post open deploy task for
> hbase:meta,,1_0001.534574363
> 2017-02-14 20:23:20,811 DEBUG [RS_OPEN_META-98410feec74d:50745-0]
> handler.OpenRegionHandler(126): Opened hbase:meta,,1_0001.534574363 on
> 98410feec74d,50745,1487103793930
> {code}
> Looks like some replica of the hbase:meta table might not have finished
> opening by the time the test asserted region location not being null.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17657) TestZKAsyncRegistry is flaky
[
https://issues.apache.org/jira/browse/HBASE-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873202#comment-15873202
]
Ted Yu commented on HBASE-17657:
bq. to detect if all the replicas for meta region is ready
TEST_UTIL.waitUntilAllRegionsAssigned(TableName.META_TABLE_NAME) does that.
But this test is about AsyncMetaRegionLocator. I searched code base. This is
the only test which references AsyncMetaRegionLocator#getMetaRegionLocation().
[~Apache9]:
Do you have suggestion how meta region location should be retrieved from
AsyncMetaRegionLocator ?
> TestZKAsyncRegistry is flaky
> -
>
> Key: HBASE-17657
> URL: https://issues.apache.org/jira/browse/HBASE-17657
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17657.v1.txt
>
>
> TestZKAsyncRegistry showed up in failed tests several times.
> On
> https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html
> , TestZKAsyncRegistry is reported flaky 33% of the time.
> e.g.
> https://builds.apache.org/job/PreCommit-HBASE-Build/5708/testReport/org.apache.hadoop.hbase.client/TestZKAsyncRegistry/test/
> Toward the end of test output:
> {code}
> 2017-02-14 20:23:20,779 WARN [main-EventThread] client.ZKAsyncRegistry(198):
> Meta region for replica 2 is in state PENDING_OPEN
> 2017-02-14 20:23:20,800 INFO [98410feec74d:45445.activeMasterManager]
> hbase.MetaTableAccessor(1767): Updated table hbase:meta state to ENABLED in
> META
> 2017-02-14 20:23:20,804 DEBUG [PostOpenDeployTasks:534574363]
> regionserver.HRegionServer(2034): Finished post open deploy task for
> hbase:meta,,1_0001.534574363
> 2017-02-14 20:23:20,811 DEBUG [RS_OPEN_META-98410feec74d:50745-0]
> handler.OpenRegionHandler(126): Opened hbase:meta,,1_0001.534574363 on
> 98410feec74d,50745,1487103793930
> {code}
> Looks like some replica of the hbase:meta table might not have finished
> opening by the time the test asserted region location not being null.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17661) fix the queue length passed to FastPathBalancedQueueRpcExecutor
[
https://issues.apache.org/jira/browse/HBASE-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17661:
--
Status: Patch Available (was: Open)
> fix the queue length passed to FastPathBalancedQueueRpcExecutor
> ---
>
> Key: HBASE-17661
> URL: https://issues.apache.org/jira/browse/HBASE-17661
> Project: HBase
> Issue Type: Bug
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17661.branch-1.v0.patch, HBASE-17661.v0.patch
>
>
> {code:title=SimpleRpcScheduler.java|borderStyle=solid}
> if (callqReadShare > 0) {
> // at least 1 read handler and 1 write handler
> callExecutor = new RWQueueRpcExecutor("deafult.RWQ", Math.max(2,
> handlerCount),
> maxQueueLength, priority, conf, server);
> } else {
> if (RpcExecutor.isFifoQueueType(callQueueType)) {
> callExecutor = new FastPathBalancedQueueRpcExecutor("deafult.FPBQ",
> handlerCount,
> maxPriorityQueueLength, priority, conf, server);
> } else {
> callExecutor = new BalancedQueueRpcExecutor("deafult.BQ",
> handlerCount, maxQueueLength,
> priority, conf, server);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17661) fix the queue length passed to FastPathBalancedQueueRpcExecutor
[
https://issues.apache.org/jira/browse/HBASE-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17661:
--
Attachment: HBASE-17661.v0.patch
> fix the queue length passed to FastPathBalancedQueueRpcExecutor
> ---
>
> Key: HBASE-17661
> URL: https://issues.apache.org/jira/browse/HBASE-17661
> Project: HBase
> Issue Type: Bug
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17661.branch-1.v0.patch, HBASE-17661.v0.patch
>
>
> {code:title=SimpleRpcScheduler.java|borderStyle=solid}
> if (callqReadShare > 0) {
> // at least 1 read handler and 1 write handler
> callExecutor = new RWQueueRpcExecutor("deafult.RWQ", Math.max(2,
> handlerCount),
> maxQueueLength, priority, conf, server);
> } else {
> if (RpcExecutor.isFifoQueueType(callQueueType)) {
> callExecutor = new FastPathBalancedQueueRpcExecutor("deafult.FPBQ",
> handlerCount,
> maxPriorityQueueLength, priority, conf, server);
> } else {
> callExecutor = new BalancedQueueRpcExecutor("deafult.BQ",
> handlerCount, maxQueueLength,
> priority, conf, server);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17661) fix the queue length passed to FastPathBalancedQueueRpcExecutor
[
https://issues.apache.org/jira/browse/HBASE-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17661:
--
Status: Open (was: Patch Available)
> fix the queue length passed to FastPathBalancedQueueRpcExecutor
> ---
>
> Key: HBASE-17661
> URL: https://issues.apache.org/jira/browse/HBASE-17661
> Project: HBase
> Issue Type: Bug
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17661.branch-1.v0.patch
>
>
> {code:title=SimpleRpcScheduler.java|borderStyle=solid}
> if (callqReadShare > 0) {
> // at least 1 read handler and 1 write handler
> callExecutor = new RWQueueRpcExecutor("deafult.RWQ", Math.max(2,
> handlerCount),
> maxQueueLength, priority, conf, server);
> } else {
> if (RpcExecutor.isFifoQueueType(callQueueType)) {
> callExecutor = new FastPathBalancedQueueRpcExecutor("deafult.FPBQ",
> handlerCount,
> maxPriorityQueueLength, priority, conf, server);
> } else {
> callExecutor = new BalancedQueueRpcExecutor("deafult.BQ",
> handlerCount, maxQueueLength,
> priority, conf, server);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17661) fix the queue length passed to FastPathBalancedQueueRpcExecutor
[
https://issues.apache.org/jira/browse/HBASE-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873158#comment-15873158
]
Hadoop QA commented on HBASE-17661:
---
| (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} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
7s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} branch-1 passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s {color} | {color:green} branch-1 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 9s
{color} | {color:red} hbase-server in branch-1 has 2 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} branch-1 passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {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}
15m 23s {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
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 87m 8s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
24s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 123m 44s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:e01ee2f |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12853423/HBASE-17661.branch-1.v0.patch
|
| JIRA Issue | HBASE-17661 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux ba997394fbcd 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-17657) TestZKAsyncRegistry is flaky
[
https://issues.apache.org/jira/browse/HBASE-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873155#comment-15873155
]
Duo Zhang commented on HBASE-17657:
---
As we are going to test ZKAsyncRegistry here, we should not rely on the result
of it when constructing the test? We should use other methods to detect if all
the replicas for meta region is ready.
> TestZKAsyncRegistry is flaky
> -
>
> Key: HBASE-17657
> URL: https://issues.apache.org/jira/browse/HBASE-17657
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17657.v1.txt
>
>
> TestZKAsyncRegistry showed up in failed tests several times.
> On
> https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html
> , TestZKAsyncRegistry is reported flaky 33% of the time.
> e.g.
> https://builds.apache.org/job/PreCommit-HBASE-Build/5708/testReport/org.apache.hadoop.hbase.client/TestZKAsyncRegistry/test/
> Toward the end of test output:
> {code}
> 2017-02-14 20:23:20,779 WARN [main-EventThread] client.ZKAsyncRegistry(198):
> Meta region for replica 2 is in state PENDING_OPEN
> 2017-02-14 20:23:20,800 INFO [98410feec74d:45445.activeMasterManager]
> hbase.MetaTableAccessor(1767): Updated table hbase:meta state to ENABLED in
> META
> 2017-02-14 20:23:20,804 DEBUG [PostOpenDeployTasks:534574363]
> regionserver.HRegionServer(2034): Finished post open deploy task for
> hbase:meta,,1_0001.534574363
> 2017-02-14 20:23:20,811 DEBUG [RS_OPEN_META-98410feec74d:50745-0]
> handler.OpenRegionHandler(126): Opened hbase:meta,,1_0001.534574363 on
> 98410feec74d,50745,1487103793930
> {code}
> Looks like some replica of the hbase:meta table might not have finished
> opening by the time the test asserted region location not being null.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17661) fix the queue length passed to FastPathBalancedQueueRpcExecutor
[
https://issues.apache.org/jira/browse/HBASE-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17661:
--
Assignee: ChiaPing Tsai
Status: Patch Available (was: Open)
> fix the queue length passed to FastPathBalancedQueueRpcExecutor
> ---
>
> Key: HBASE-17661
> URL: https://issues.apache.org/jira/browse/HBASE-17661
> Project: HBase
> Issue Type: Bug
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17661.branch-1.v0.patch
>
>
> {code:title=SimpleRpcScheduler.java|borderStyle=solid}
> if (callqReadShare > 0) {
> // at least 1 read handler and 1 write handler
> callExecutor = new RWQueueRpcExecutor("deafult.RWQ", Math.max(2,
> handlerCount),
> maxQueueLength, priority, conf, server);
> } else {
> if (RpcExecutor.isFifoQueueType(callQueueType)) {
> callExecutor = new FastPathBalancedQueueRpcExecutor("deafult.FPBQ",
> handlerCount,
> maxPriorityQueueLength, priority, conf, server);
> } else {
> callExecutor = new BalancedQueueRpcExecutor("deafult.BQ",
> handlerCount, maxQueueLength,
> priority, conf, server);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17661) fix the queue length passed to FastPathBalancedQueueRpcExecutor
[
https://issues.apache.org/jira/browse/HBASE-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17661:
--
Attachment: HBASE-17661.branch-1.v0.patch
> fix the queue length passed to FastPathBalancedQueueRpcExecutor
> ---
>
> Key: HBASE-17661
> URL: https://issues.apache.org/jira/browse/HBASE-17661
> Project: HBase
> Issue Type: Bug
>Reporter: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17661.branch-1.v0.patch
>
>
> {code:title=SimpleRpcScheduler.java|borderStyle=solid}
> if (callqReadShare > 0) {
> // at least 1 read handler and 1 write handler
> callExecutor = new RWQueueRpcExecutor("deafult.RWQ", Math.max(2,
> handlerCount),
> maxQueueLength, priority, conf, server);
> } else {
> if (RpcExecutor.isFifoQueueType(callQueueType)) {
> callExecutor = new FastPathBalancedQueueRpcExecutor("deafult.FPBQ",
> handlerCount,
> maxPriorityQueueLength, priority, conf, server);
> } else {
> callExecutor = new BalancedQueueRpcExecutor("deafult.BQ",
> handlerCount, maxQueueLength,
> priority, conf, server);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17661) fix the queue length passed to FastPathBalancedQueueRpcExecutor
[
https://issues.apache.org/jira/browse/HBASE-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-17661:
--
Summary: fix the queue length passed to FastPathBalancedQueueRpcExecutor
(was: fix the queue size passed to FastPathBalancedQueueRpcExecutor)
> fix the queue length passed to FastPathBalancedQueueRpcExecutor
> ---
>
> Key: HBASE-17661
> URL: https://issues.apache.org/jira/browse/HBASE-17661
> Project: HBase
> Issue Type: Bug
>Reporter: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
>
> {code:title=SimpleRpcScheduler.java|borderStyle=solid}
> if (callqReadShare > 0) {
> // at least 1 read handler and 1 write handler
> callExecutor = new RWQueueRpcExecutor("deafult.RWQ", Math.max(2,
> handlerCount),
> maxQueueLength, priority, conf, server);
> } else {
> if (RpcExecutor.isFifoQueueType(callQueueType)) {
> callExecutor = new FastPathBalancedQueueRpcExecutor("deafult.FPBQ",
> handlerCount,
> maxPriorityQueueLength, priority, conf, server);
> } else {
> callExecutor = new BalancedQueueRpcExecutor("deafult.BQ",
> handlerCount, maxQueueLength,
> priority, conf, server);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17661) fix the queue size passed to FastPathBalancedQueueRpcExecutor
ChiaPing Tsai created HBASE-17661:
-
Summary: fix the queue size passed to
FastPathBalancedQueueRpcExecutor
Key: HBASE-17661
URL: https://issues.apache.org/jira/browse/HBASE-17661
Project: HBase
Issue Type: Bug
Reporter: ChiaPing Tsai
Priority: Minor
Fix For: 2.0.0, 1.4.0
{code:title=SimpleRpcScheduler.java|borderStyle=solid}
if (callqReadShare > 0) {
// at least 1 read handler and 1 write handler
callExecutor = new RWQueueRpcExecutor("deafult.RWQ", Math.max(2,
handlerCount),
maxQueueLength, priority, conf, server);
} else {
if (RpcExecutor.isFifoQueueType(callQueueType)) {
callExecutor = new FastPathBalancedQueueRpcExecutor("deafult.FPBQ",
handlerCount,
maxPriorityQueueLength, priority, conf, server);
} else {
callExecutor = new BalancedQueueRpcExecutor("deafult.BQ", handlerCount,
maxQueueLength,
priority, conf, server);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors
[
https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873096#comment-15873096
]
Appy commented on HBASE-17312:
--
Uploaded the new patch (002) and added RB link.
> [JDK8] Use default method for Observer Coprocessors
> ---
>
> Key: HBASE-17312
> URL: https://issues.apache.org/jira/browse/HBASE-17312
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Appy
> Labels: incompatible
> Attachments: HBASE-17312.master.001.patch,
> HBASE-17312.master.001.patch, HBASE-17312.master.002.patch
>
>
> In cases where one might need to use multiple observers, say region, master
> and regionserver; and the fact that only one class can be extended, it gives
> rise to following pattern:
> {noformat}
> public class BaseMasterAndRegionObserver
> extends BaseRegionObserver
> implements MasterObserver
> class AccessController
> extends BaseMasterAndRegionObserver
> implements RegionServerObserver
> {noformat}
> were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
> There is an example of simple case too where the current design fails.
> Say only one observer is needed by the coprocessor, but the design doesn't
> permit extending even that single observer (see RSGroupAdminEndpoint), that
> leads to full copy of Base...Observer class into coprocessor class leading to
> 1000s of lines of code and this ugly mix of 5 main functions with 100 useless
> functions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors
[
https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy updated HBASE-17312:
-
Attachment: HBASE-17312.master.002.patch
> [JDK8] Use default method for Observer Coprocessors
> ---
>
> Key: HBASE-17312
> URL: https://issues.apache.org/jira/browse/HBASE-17312
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Appy
> Labels: incompatible
> Attachments: HBASE-17312.master.001.patch,
> HBASE-17312.master.001.patch, HBASE-17312.master.002.patch
>
>
> In cases where one might need to use multiple observers, say region, master
> and regionserver; and the fact that only one class can be extended, it gives
> rise to following pattern:
> {noformat}
> public class BaseMasterAndRegionObserver
> extends BaseRegionObserver
> implements MasterObserver
> class AccessController
> extends BaseMasterAndRegionObserver
> implements RegionServerObserver
> {noformat}
> were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
> There is an example of simple case too where the current design fails.
> Say only one observer is needed by the coprocessor, but the design doesn't
> permit extending even that single observer (see RSGroupAdminEndpoint), that
> leads to full copy of Base...Observer class into coprocessor class leading to
> 1000s of lines of code and this ugly mix of 5 main functions with 100 useless
> functions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors
[
https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy reassigned HBASE-17312:
Assignee: Appy (was: Guanghao Zhang)
> [JDK8] Use default method for Observer Coprocessors
> ---
>
> Key: HBASE-17312
> URL: https://issues.apache.org/jira/browse/HBASE-17312
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Appy
> Labels: incompatible
> Attachments: HBASE-17312.master.001.patch,
> HBASE-17312.master.001.patch
>
>
> In cases where one might need to use multiple observers, say region, master
> and regionserver; and the fact that only one class can be extended, it gives
> rise to following pattern:
> {noformat}
> public class BaseMasterAndRegionObserver
> extends BaseRegionObserver
> implements MasterObserver
> class AccessController
> extends BaseMasterAndRegionObserver
> implements RegionServerObserver
> {noformat}
> were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
> There is an example of simple case too where the current design fails.
> Say only one observer is needed by the coprocessor, but the design doesn't
> permit extending even that single observer (see RSGroupAdminEndpoint), that
> leads to full copy of Base...Observer class into coprocessor class leading to
> 1000s of lines of code and this ugly mix of 5 main functions with 100 useless
> functions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors
[
https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy updated HBASE-17312:
-
Labels: incompatible (was: )
> [JDK8] Use default method for Observer Coprocessors
> ---
>
> Key: HBASE-17312
> URL: https://issues.apache.org/jira/browse/HBASE-17312
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Appy
> Labels: incompatible
> Attachments: HBASE-17312.master.001.patch,
> HBASE-17312.master.001.patch
>
>
> In cases where one might need to use multiple observers, say region, master
> and regionserver; and the fact that only one class can be extended, it gives
> rise to following pattern:
> {noformat}
> public class BaseMasterAndRegionObserver
> extends BaseRegionObserver
> implements MasterObserver
> class AccessController
> extends BaseMasterAndRegionObserver
> implements RegionServerObserver
> {noformat}
> were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
> There is an example of simple case too where the current design fails.
> Say only one observer is needed by the coprocessor, but the design doesn't
> permit extending even that single observer (see RSGroupAdminEndpoint), that
> leads to full copy of Base...Observer class into coprocessor class leading to
> 1000s of lines of code and this ugly mix of 5 main functions with 100 useless
> functions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors
[
https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy updated HBASE-17312:
-
Description:
In cases where one might need to use multiple observers, say region, master and
regionserver; and the fact that only one class can be extended, it gives rise
to following pattern:
{noformat}
public class BaseMasterAndRegionObserver
extends BaseRegionObserver
implements MasterObserver
class AccessController
extends BaseMasterAndRegionObserver
implements RegionServerObserver
{noformat}
were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
There is an example of simple case too where the current design fails.
Say only one observer is needed by the coprocessor, but the design doesn't
permit extending even that single observer (see RSGroupAdminEndpoint), that
leads to full copy of Base...Observer class into coprocessor class leading to
1000s of lines of code and this ugly mix of 5 main functions with 100 useless
functions.
was:Use default method in MasterObserver, RegionObserver,
RegionServerObserver and WALObserver. And mark the BaseRegionObserver,
BaseMasterAndRegionObserver, BaseRegionServerObserver and BaseWALObserver. User
can implement the interface directly and will not break compatibility when add
new default methods.
> [JDK8] Use default method for Observer Coprocessors
> ---
>
> Key: HBASE-17312
> URL: https://issues.apache.org/jira/browse/HBASE-17312
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Labels: incompatible
> Attachments: HBASE-17312.master.001.patch,
> HBASE-17312.master.001.patch
>
>
> In cases where one might need to use multiple observers, say region, master
> and regionserver; and the fact that only one class can be extended, it gives
> rise to following pattern:
> {noformat}
> public class BaseMasterAndRegionObserver
> extends BaseRegionObserver
> implements MasterObserver
> class AccessController
> extends BaseMasterAndRegionObserver
> implements RegionServerObserver
> {noformat}
> were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
> There is an example of simple case too where the current design fails.
> Say only one observer is needed by the coprocessor, but the design doesn't
> permit extending even that single observer (see RSGroupAdminEndpoint), that
> leads to full copy of Base...Observer class into coprocessor class leading to
> 1000s of lines of code and this ugly mix of 5 main functions with 100 useless
> functions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors
[ https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873092#comment-15873092 ] Appy commented on HBASE-17312: -- In that case, i'll try to see it through. Will upload new patch and RB shortly. > [JDK8] Use default method for Observer Coprocessors > --- > > Key: HBASE-17312 > URL: https://issues.apache.org/jira/browse/HBASE-17312 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 2.0.0 >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-17312.master.001.patch, > HBASE-17312.master.001.patch > > > Use default method in MasterObserver, RegionObserver, RegionServerObserver > and WALObserver. And mark the BaseRegionObserver, > BaseMasterAndRegionObserver, BaseRegionServerObserver and BaseWALObserver. > User can implement the interface directly and will not break compatibility > when add new default methods. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
