[jira] [Commented] (HBASE-19522) The complete order may be wrong in AsyncBufferedMutatorImpl
[
https://issues.apache.org/jira/browse/HBASE-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293785#comment-16293785
]
Hudson commented on HBASE-19522:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4235 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4235/])
HBASE-19522 The complete order may be wrong in AsyncBufferedMutatorImpl (zghao:
rev 979767824d37df0e05002fa76402ff2b9e534d50)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncBufferMutator.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncBufferedMutatorImpl.java
> The complete order may be wrong in AsyncBufferedMutatorImpl
> ---
>
> Key: HBASE-19522
> URL: https://issues.apache.org/jira/browse/HBASE-19522
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19522.master.001.patch,
> HBASE-19522.master.002.patch
>
>
> {code}
> List toComplete = this.futures;
> assert toSend.size() == toComplete.size();
> this.mutations = new ArrayList<>();
> this.futures = new ArrayList<>();
> bufferedSize = 0L;
> Iterator toCompleteIter = toComplete.iterator();
> for (CompletableFuture future : table.batch(toSend)) {
> future.whenComplete((r, e) -> {
> CompletableFuture f = toCompleteIter.next(); // Call next in
> callback, so the complete order may different with the future order
> if (e != null) {
> f.completeExceptionally(e);
> } else {
> f.complete(null);
> }
> });
> }
> {code}
> Here we call table.batch to get a list of CompleteFuture for each mutation.
> Then we register a call back for each future. But the problem is we call
> toCompleteIter.next() in the callback. So we may complete the future by a
> wrong order(not same with the mutation order). Meanwhile, as ArrayList is not
> thread safe, so different thread may get same future by toCompleteIter.next().
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19522) The complete order may be wrong in AsyncBufferedMutatorImpl
[
https://issues.apache.org/jira/browse/HBASE-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293671#comment-16293671
]
Guanghao Zhang commented on HBASE-19522:
The failed ut not related. Will commit it shortly.
> The complete order may be wrong in AsyncBufferedMutatorImpl
> ---
>
> Key: HBASE-19522
> URL: https://issues.apache.org/jira/browse/HBASE-19522
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Attachments: HBASE-19522.master.001.patch,
> HBASE-19522.master.002.patch
>
>
> {code}
> List toComplete = this.futures;
> assert toSend.size() == toComplete.size();
> this.mutations = new ArrayList<>();
> this.futures = new ArrayList<>();
> bufferedSize = 0L;
> Iterator toCompleteIter = toComplete.iterator();
> for (CompletableFuture future : table.batch(toSend)) {
> future.whenComplete((r, e) -> {
> CompletableFuture f = toCompleteIter.next(); // Call next in
> callback, so the complete order may different with the future order
> if (e != null) {
> f.completeExceptionally(e);
> } else {
> f.complete(null);
> }
> });
> }
> {code}
> Here we call table.batch to get a list of CompleteFuture for each mutation.
> Then we register a call back for each future. But the problem is we call
> toCompleteIter.next() in the callback. So we may complete the future by a
> wrong order(not same with the mutation order). Meanwhile, as ArrayList is not
> thread safe, so different thread may get same future by toCompleteIter.next().
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19522) The complete order may be wrong in AsyncBufferedMutatorImpl
[
https://issues.apache.org/jira/browse/HBASE-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293633#comment-16293633
]
Hadoop QA commented on HBASE-19522:
---
| (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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
33s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
44s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
10s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
17m 49s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0-beta1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
35s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 99m 56s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
41s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}141m 5s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19522 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12902477/HBASE-19522.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 7cda2e590912 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / f9f869f60a |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit |
[jira] [Commented] (HBASE-19522) The complete order may be wrong in AsyncBufferedMutatorImpl
[
https://issues.apache.org/jira/browse/HBASE-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293549#comment-16293549
]
Guanghao Zhang commented on HBASE-19522:
Will commit this after see HADOOP QA result. Thanks [~tedyu] for reviewing.
> The complete order may be wrong in AsyncBufferedMutatorImpl
> ---
>
> Key: HBASE-19522
> URL: https://issues.apache.org/jira/browse/HBASE-19522
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Attachments: HBASE-19522.master.001.patch,
> HBASE-19522.master.002.patch
>
>
> {code}
> List toComplete = this.futures;
> assert toSend.size() == toComplete.size();
> this.mutations = new ArrayList<>();
> this.futures = new ArrayList<>();
> bufferedSize = 0L;
> Iterator toCompleteIter = toComplete.iterator();
> for (CompletableFuture future : table.batch(toSend)) {
> future.whenComplete((r, e) -> {
> CompletableFuture f = toCompleteIter.next(); // Call next in
> callback, so the complete order may different with the future order
> if (e != null) {
> f.completeExceptionally(e);
> } else {
> f.complete(null);
> }
> });
> }
> {code}
> Here we call table.batch to get a list of CompleteFuture for each mutation.
> Then we register a call back for each future. But the problem is we call
> toCompleteIter.next() in the callback. So we may complete the future by a
> wrong order(not same with the mutation order). Meanwhile, as ArrayList is not
> thread safe, so different thread may get same future by toCompleteIter.next().
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19522) The complete order may be wrong in AsyncBufferedMutatorImpl
[
https://issues.apache.org/jira/browse/HBASE-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293548#comment-16293548
]
Guanghao Zhang commented on HBASE-19522:
Add a new ut in 002 patch.
> The complete order may be wrong in AsyncBufferedMutatorImpl
> ---
>
> Key: HBASE-19522
> URL: https://issues.apache.org/jira/browse/HBASE-19522
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Attachments: HBASE-19522.master.001.patch,
> HBASE-19522.master.002.patch
>
>
> {code}
> List toComplete = this.futures;
> assert toSend.size() == toComplete.size();
> this.mutations = new ArrayList<>();
> this.futures = new ArrayList<>();
> bufferedSize = 0L;
> Iterator toCompleteIter = toComplete.iterator();
> for (CompletableFuture future : table.batch(toSend)) {
> future.whenComplete((r, e) -> {
> CompletableFuture f = toCompleteIter.next(); // Call next in
> callback, so the complete order may different with the future order
> if (e != null) {
> f.completeExceptionally(e);
> } else {
> f.complete(null);
> }
> });
> }
> {code}
> Here we call table.batch to get a list of CompleteFuture for each mutation.
> Then we register a call back for each future. But the problem is we call
> toCompleteIter.next() in the callback. So we may complete the future by a
> wrong order(not same with the mutation order). Meanwhile, as ArrayList is not
> thread safe, so different thread may get same future by toCompleteIter.next().
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19522) The complete order may be wrong in AsyncBufferedMutatorImpl
[
https://issues.apache.org/jira/browse/HBASE-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292696#comment-16292696
]
Ted Yu commented on HBASE-19522:
lgtm
> The complete order may be wrong in AsyncBufferedMutatorImpl
> ---
>
> Key: HBASE-19522
> URL: https://issues.apache.org/jira/browse/HBASE-19522
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Attachments: HBASE-19522.master.001.patch
>
>
> {code}
> List toComplete = this.futures;
> assert toSend.size() == toComplete.size();
> this.mutations = new ArrayList<>();
> this.futures = new ArrayList<>();
> bufferedSize = 0L;
> Iterator toCompleteIter = toComplete.iterator();
> for (CompletableFuture future : table.batch(toSend)) {
> future.whenComplete((r, e) -> {
> CompletableFuture f = toCompleteIter.next(); // Call next in
> callback, so the complete order may different with the future order
> if (e != null) {
> f.completeExceptionally(e);
> } else {
> f.complete(null);
> }
> });
> }
> {code}
> Here we call table.batch to get a list of CompleteFuture for each mutation.
> Then we register a call back for each future. But the problem is we call
> toCompleteIter.next() in the callback. So we may complete the future by a
> wrong order(not same with the mutation order). Meanwhile, as ArrayList is not
> thread safe, so different thread may get same future by toCompleteIter.next().
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19522) The complete order may be wrong in AsyncBufferedMutatorImpl
[
https://issues.apache.org/jira/browse/HBASE-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292430#comment-16292430
]
Hadoop QA commented on HBASE-19522:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
30s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
23s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {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} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {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} shadedjars {color} | {color:green} 4m
22s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
18m 48s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0-beta1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
34s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 39m 54s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19522 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12902284/HBASE-19522.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux e48018df2631 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 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 / 018a65b947 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10476/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10476/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> The complete order may be wrong in AsyncBufferedMutatorImpl
>
