[jira] [Commented] (HBASE-16519) Procedure v2 - Avoid sync wait on DDLs operation
[ https://issues.apache.org/jira/browse/HBASE-16519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15449706#comment-15449706 ] Hudson commented on HBASE-16519: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1510 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1510/]) HBASE-16519 Procedure v2 - Avoid sync wait on DDLs operation (matteo.bertozzi: rev 4a4f8e704903f02dac38d584ab85a472a9f3d2ce) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/ProcedurePrepareLatch.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/ProcedureSyncWait.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/TruncateTableProcedure.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/DeleteColumnFamilyProcedure.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/ModifyColumnFamilyProcedure.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/AddColumnFamilyProcedure.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/ModifyTableProcedure.java > Procedure v2 - Avoid sync wait on DDLs operation > > > Key: HBASE-16519 > URL: https://issues.apache.org/jira/browse/HBASE-16519 > Project: HBase > Issue Type: Sub-task > Components: master, proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-16519-v0.patch > > > Some operation ModifyColumnFamily, AddDeleteColumnFamily, DeleteColumnFamily, > ModifyTable, TruncateTable are still synchronous on the master side. with a > wait until the operation completes before returning. > this was done to keep the sync behavior for old client. but instead of using > the procLatch which recognize the client version and decide if the operation > should be sync or not it just always wait. making the client side proc fault > tolerance ineffective. > also the add/delete/modifyColumnFamily operation does not seems to follow the > Async() naming in master. and the comment claim to be async but everyone uses > them as sync. (this is something from HBASE-13538) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16519) Procedure v2 - Avoid sync wait on DDLs operation
[ https://issues.apache.org/jira/browse/HBASE-16519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15449333#comment-15449333 ] Stephen Yuan Jiang commented on HBASE-16519: patch LGTM > Procedure v2 - Avoid sync wait on DDLs operation > > > Key: HBASE-16519 > URL: https://issues.apache.org/jira/browse/HBASE-16519 > Project: HBase > Issue Type: Sub-task > Components: master, proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-16519-v0.patch > > > Some operation ModifyColumnFamily, AddDeleteColumnFamily, DeleteColumnFamily, > ModifyTable, TruncateTable are still synchronous on the master side. with a > wait until the operation completes before returning. > this was done to keep the sync behavior for old client. but instead of using > the procLatch which recognize the client version and decide if the operation > should be sync or not it just always wait. making the client side proc fault > tolerance ineffective. > also the add/delete/modifyColumnFamily operation does not seems to follow the > Async() naming in master. and the comment claim to be async but everyone uses > them as sync. (this is something from HBASE-13538) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16519) Procedure v2 - Avoid sync wait on DDLs operation
[ https://issues.apache.org/jira/browse/HBASE-16519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15449087#comment-15449087 ] Matteo Bertozzi commented on HBASE-16519: - the latch is a noop if the client is 2.0, if the client is a 1.x it behaves in a sync way. like we do already for create/delete/enable/disable. those procedures are already in 1.x, and the client code relies on the fact that the server behavior is sync. so we need the latch for compatibility > Procedure v2 - Avoid sync wait on DDLs operation > > > Key: HBASE-16519 > URL: https://issues.apache.org/jira/browse/HBASE-16519 > Project: HBase > Issue Type: Sub-task > Components: master, proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-16519-v0.patch > > > Some operation ModifyColumnFamily, AddDeleteColumnFamily, DeleteColumnFamily, > ModifyTable, TruncateTable are still synchronous on the master side. with a > wait until the operation completes before returning. > this was done to keep the sync behavior for old client. but instead of using > the procLatch which recognize the client version and decide if the operation > should be sync or not it just always wait. making the client side proc fault > tolerance ineffective. > also the add/delete/modifyColumnFamily operation does not seems to follow the > Async() naming in master. and the comment claim to be async but everyone uses > them as sync. (this is something from HBASE-13538) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16519) Procedure v2 - Avoid sync wait on DDLs operation
[ https://issues.apache.org/jira/browse/HBASE-16519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15448226#comment-15448226 ] Stephen Yuan Jiang commented on HBASE-16519: Do we really need latch in 2.0 branch? Those async procedure are new in 2.0 > Procedure v2 - Avoid sync wait on DDLs operation > > > Key: HBASE-16519 > URL: https://issues.apache.org/jira/browse/HBASE-16519 > Project: HBase > Issue Type: Sub-task > Components: master, proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-16519-v0.patch > > > Some operation ModifyColumnFamily, AddDeleteColumnFamily, DeleteColumnFamily, > ModifyTable, TruncateTable are still synchronous on the master side. with a > wait until the operation completes before returning. > this was done to keep the sync behavior for old client. but instead of using > the procLatch which recognize the client version and decide if the operation > should be sync or not it just always wait. making the client side proc fault > tolerance ineffective. > also the add/delete/modifyColumnFamily operation does not seems to follow the > Async() naming in master. and the comment claim to be async but everyone uses > them as sync. (this is something from HBASE-13538) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16519) Procedure v2 - Avoid sync wait on DDLs operation
[
https://issues.apache.org/jira/browse/HBASE-16519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447576#comment-15447576
]
Hadoop QA commented on HBASE-16519:
---
| (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} @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 22s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
41s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 56s
{color} | {color:green} master passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 53s
{color} | {color:green} master passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s {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
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 41s
{color} | {color:green} master passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} master passed with JDK v1.7.0_111 {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
5s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 46s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 52s
{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 52s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
28s {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 47s {color} | {color:green} 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
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
23s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 1s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 112m 56s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
47s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 164m 45s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestMasterFailoverWithProcedures |
| Timed out junit tests |
