[jira] [Commented] (RATIS-386) Raft Client Async API's should honor Retry Policy
[
https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687609#comment-16687609
]
Hadoop QA commented on RATIS-386:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color: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} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
28s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
41s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
6s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
0m 14s{color} | {color:orange} root: The patch generated 5 new + 14 unchanged -
1 fixed = 19 total (was 15) {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} javadoc {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 11m 11s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 19m 43s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | ratis.grpc.TestRaftAsyncWithGrpc |
| | ratis.grpc.TestWatchRequestWithGrpc |
| | ratis.netty.TestServerRestartWithNetty |
| | ratis.TestRetryPolicy |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/ratis:date2018-11-15
|
| JIRA Issue | RATIS-386 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12948271/RATIS-386.002.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
checkstyle compile |
| uname | Linux 1015012a457c 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-RATIS-Build/yetus-personality.sh
|
| git revision | master / 1e8b234 |
| maven | version: Apache Maven 3.6.0
(97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T18:41:47Z) |
| Default Java | 1.8.0_181 |
| checkstyle |
https://builds.apache.org/job/PreCommit-RATIS-Build/523/artifact/out/diff-checkstyle-root.txt
|
| unit |
https://builds.apache.org/job/PreCommit-RATIS-Build/523/artifact/out/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-RATIS-Build/523/testReport/ |
| Max. process+thread count | 3125 (vs. ulimit of 5000) |
| modules | C: ratis-common ratis-client ratis-server ratis-grpc U: . |
| Console output |
https://builds.apache.org/job/PreCommit-RATIS-Build/523/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Raft Client Async API's should honor Retry Policy
> --
>
> Key: RATIS-386
>
[jira] [Commented] (RATIS-386) Raft Client Async API's should honor Retry Policy
[ https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687585#comment-16687585 ] Shashikant Banerjee commented on RATIS-386: --- Patch v3 addresses the issues discussed. > Raft Client Async API's should honor Retry Policy > -- > > Key: RATIS-386 > URL: https://issues.apache.org/jira/browse/RATIS-386 > Project: Ratis > Issue Type: Improvement > Components: client >Affects Versions: 0.3.0 >Reporter: Shashikant Banerjee >Assignee: Shashikant Banerjee >Priority: Major > Fix For: 0.3.0 > > Attachments: RATIS-386.001.patch, RATIS-386.002.patch > > > Raft client sync Api has support for retry policies. Similarly, for Async > API's including watch Api, support for Retry Policy is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RATIS-378) Consolidate MasterServer and LogServiceWorker
[ https://issues.apache.org/jira/browse/RATIS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated RATIS-378: - Attachment: RATIS-378.wip.patch > Consolidate MasterServer and LogServiceWorker > - > > Key: RATIS-378 > URL: https://issues.apache.org/jira/browse/RATIS-378 > Project: Ratis > Issue Type: Improvement > Components: LogService >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: newbie > Attachments: RATIS-378.wip.patch > > > There should be a large overlap of the "arguments" used to launch a > MetaService SM and a LogService SM. > It would be nice to consolidate MasterServer and LogServiceWorker into a > single class. Each can specify an extra arguments that they need to add (in > addition to the common) arguments. > FYI [~vrodionov], [~sergey.soldatov] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-378) Consolidate MasterServer and LogServiceWorker
[ https://issues.apache.org/jira/browse/RATIS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687569#comment-16687569 ] Josh Elser commented on RATIS-378: -- Things not quite working here, but this has been sitting locally too long. Need to come back to it. A quorum isn't forming which makes me think I messed up the configuration somewhere. (or, it's the hotel wifi i'm on...) > Consolidate MasterServer and LogServiceWorker > - > > Key: RATIS-378 > URL: https://issues.apache.org/jira/browse/RATIS-378 > Project: Ratis > Issue Type: Improvement > Components: LogService >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: newbie > Attachments: RATIS-378.wip.patch > > > There should be a large overlap of the "arguments" used to launch a > MetaService SM and a LogService SM. > It would be nice to consolidate MasterServer and LogServiceWorker into a > single class. Each can specify an extra arguments that they need to add (in > addition to the common) arguments. > FYI [~vrodionov], [~sergey.soldatov] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-409) Watch requests may not work if there is a conf change
[
https://issues.apache.org/jira/browse/RATIS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687494#comment-16687494
]
Jitendra Nath Pandey commented on RATIS-409:
{{leaderState.commitIndexChanged()}} is being called in
LogAppender#updateCommitIndex as well. Doe that mean this codepath doesn't
change index for {{ReplicationLevel.MAJORITY?}}
> Watch requests may not work if there is a conf change
> -
>
> Key: RATIS-409
> URL: https://issues.apache.org/jira/browse/RATIS-409
> Project: Ratis
> Issue Type: Bug
> Components: server
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
>Priority: Major
> Attachments: r409_20181112.patch, r409_20181113.patch,
> r409_20181113b.patch
>
>
> When there is commitIndex changed, the watchRequests is updated with the
> indices in SenderList. However, when there is a conf change, SenderList
> includes all servers in both old and new confs. As a result, the computed
> indices may be incorrect.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RATIS-386) Raft Client Async API's should honor Retry Policy
[
https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687417#comment-16687417
]
Hadoop QA commented on RATIS-386:
-
| (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} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
6s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
0m 14s{color} | {color:orange} root: The patch generated 1 new + 4 unchanged -
0 fixed = 5 total (was 4) {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} javadoc {color} | {color:green} 0m
33s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 16m 0s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 24m 37s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | ratis.TestBatchAppend |
| | ratis.TestRetryPolicy |
| | ratis.netty.TestServerRestartWithNetty |
| | ratis.grpc.TestWatchRequestWithGrpc |
| | ratis.netty.TestRaftReconfigurationWithNetty |
| | ratis.netty.TestRaftWithNetty |
| | ratis.grpc.TestRaftReconfigurationWithGrpc |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/ratis:date2018-11-15
|
| JIRA Issue | RATIS-386 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12948242/RATIS-386.001.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
checkstyle compile |
| uname | Linux 18f82d6d7b4d 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-RATIS-Build/yetus-personality.sh
|
| git revision | master / 1e8b234 |
| maven | version: Apache Maven 3.6.0
(97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T18:41:47Z) |
| Default Java | 1.8.0_181 |
| checkstyle |
https://builds.apache.org/job/PreCommit-RATIS-Build/522/artifact/out/diff-checkstyle-root.txt
|
| unit |
https://builds.apache.org/job/PreCommit-RATIS-Build/522/artifact/out/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-RATIS-Build/522/testReport/ |
| Max. process+thread count | 4010 (vs. ulimit of 5000) |
| modules | C: ratis-common ratis-client ratis-server ratis-grpc U: . |
| Console output |
https://builds.apache.org/job/PreCommit-RATIS-Build/522/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Raft Client Async
[jira] [Commented] (RATIS-386) Raft Client Async API's should honor Retry Policy
[ https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687401#comment-16687401 ] Shashikant Banerjee commented on RATIS-386: --- Thanks [~szetszwo], as per our discussion/comments, updated patch v1. > Raft Client Async API's should honor Retry Policy > -- > > Key: RATIS-386 > URL: https://issues.apache.org/jira/browse/RATIS-386 > Project: Ratis > Issue Type: Improvement > Components: client >Affects Versions: 0.3.0 >Reporter: Shashikant Banerjee >Assignee: Shashikant Banerjee >Priority: Major > Fix For: 0.3.0 > > Attachments: RATIS-386.001.patch > > > Raft client sync Api has support for retry policies. Similarly, for Async > API's including watch Api, support for Retry Policy is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RATIS-386) Raft Client Async API's should honor Retry Policy
[ https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shashikant Banerjee updated RATIS-386: -- Attachment: RATIS-386.001.patch > Raft Client Async API's should honor Retry Policy > -- > > Key: RATIS-386 > URL: https://issues.apache.org/jira/browse/RATIS-386 > Project: Ratis > Issue Type: Improvement > Components: client >Affects Versions: 0.3.0 >Reporter: Shashikant Banerjee >Assignee: Shashikant Banerjee >Priority: Major > Fix For: 0.3.0 > > Attachments: RATIS-386.001.patch > > > Raft client sync Api has support for retry policies. Similarly, for Async > API's including watch Api, support for Retry Policy is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RATIS-386) Raft Client Async API's should honor Retry Policy
[ https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shashikant Banerjee updated RATIS-386: -- Attachment: (was: RATIS-386.000.patch) > Raft Client Async API's should honor Retry Policy > -- > > Key: RATIS-386 > URL: https://issues.apache.org/jira/browse/RATIS-386 > Project: Ratis > Issue Type: Improvement > Components: client >Affects Versions: 0.3.0 >Reporter: Shashikant Banerjee >Assignee: Shashikant Banerjee >Priority: Major > Fix For: 0.3.0 > > Attachments: RATIS-386.001.patch > > > Raft client sync Api has support for retry policies. Similarly, for Async > API's including watch Api, support for Retry Policy is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RATIS-386) Raft Client Async API's should honor Retry Policy
[ https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shashikant Banerjee updated RATIS-386: -- Attachment: (was: RATIS-386.001.patch) > Raft Client Async API's should honor Retry Policy > -- > > Key: RATIS-386 > URL: https://issues.apache.org/jira/browse/RATIS-386 > Project: Ratis > Issue Type: Improvement > Components: client >Affects Versions: 0.3.0 >Reporter: Shashikant Banerjee >Assignee: Shashikant Banerjee >Priority: Major > Fix For: 0.3.0 > > Attachments: RATIS-386.001.patch > > > Raft client sync Api has support for retry policies. Similarly, for Async > API's including watch Api, support for Retry Policy is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RATIS-386) Raft Client Async API's should honor Retry Policy
[ https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shashikant Banerjee updated RATIS-386: -- Attachment: RATIS-386.001.patch > Raft Client Async API's should honor Retry Policy > -- > > Key: RATIS-386 > URL: https://issues.apache.org/jira/browse/RATIS-386 > Project: Ratis > Issue Type: Improvement > Components: client >Affects Versions: 0.3.0 >Reporter: Shashikant Banerjee >Assignee: Shashikant Banerjee >Priority: Major > Fix For: 0.3.0 > > Attachments: RATIS-386.000.patch, RATIS-386.001.patch > > > Raft client sync Api has support for retry policies. Similarly, for Async > API's including watch Api, support for Retry Policy is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (RATIS-415) Disable checkstyle DesignForExtension rule
[ https://issues.apache.org/jira/browse/RATIS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo Nicholas Sze reassigned RATIS-415: - Assignee: Tsz Wo Nicholas Sze Description: The DesignForExtension rule only useful in public API but not implementations. Let's disable it for now. (was: - RaftClientRpcWithProxy.java:[36,3] (design) DesignForExtension: Method 'getProxies' is not designed for extension - needs to be abstract, final or empty. - RaftClientRpcWithProxy.java:[40,3] (design) DesignForExtension: Method 'addServers' is not designed for extension - needs to be abstract, final or empty. - RaftClientRpcWithProxy.java:[45,3] (design) DesignForExtension: Method 'handleException' is not designed for extension - needs to be abstract, final or empty. - RaftClientRpcWithProxy.java:[50,3] (design) DesignForExtension: Method 'close' is not designed for extension - needs to be abstract, final or empty. ) Component/s: build Summary: Disable checkstyle DesignForExtension rule (was: Fix checkstyle warnings in RaftClientRpcWithProxy) > Disable checkstyle DesignForExtension rule > -- > > Key: RATIS-415 > URL: https://issues.apache.org/jira/browse/RATIS-415 > Project: Ratis > Issue Type: Sub-task > Components: build >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze >Priority: Major > > The DesignForExtension rule only useful in public API but not > implementations. Let's disable it for now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RATIS-417) Fix checkstyle warnings in PureJavaCrc32C
Tsz Wo Nicholas Sze created RATIS-417: - Summary: Fix checkstyle warnings in PureJavaCrc32C Key: RATIS-417 URL: https://issues.apache.org/jira/browse/RATIS-417 Project: Ratis Issue Type: Sub-task Reporter: Tsz Wo Nicholas Sze * PureJavaCrc32C.java:[17] (regexp) RegexpSingleline: Line has trailing spaces. - PureJavaCrc32C.java:[40,3] (design) DesignForExtension: Method 'getValue' is not designed for extension - needs to be abstract, final or empty. - PureJavaCrc32C.java:[46,3] (design) DesignForExtension: Method 'reset' is not designed for extension - needs to be abstract, final or empty. - PureJavaCrc32C.java:[51,3] (design) DesignForExtension: Method 'update' is not designed for extension - needs to be abstract, final or empty. - PureJavaCrc32C.java:[87] (regexp) RegexpSingleline: Line has trailing spaces. - PureJavaCrc32C.java:[93,9] (modifier) ModifierOrder: 'public' modifier out of order with the JLS suggestions. - PureJavaCrc32C.java:[96] (regexp) RegexpSingleline: Line has trailing spaces. - PureJavaCrc32C.java:[101,28] (naming) ConstantName: Name 'T8_0_start' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. - PureJavaCrc32C.java:[102,28] (naming) ConstantName: Name 'T8_1_start' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. - PureJavaCrc32C.java:[103,28] (naming) ConstantName: Name 'T8_2_start' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. - PureJavaCrc32C.java:[104,28] (naming) ConstantName: Name 'T8_3_start' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. - PureJavaCrc32C.java:[105,28] (naming) ConstantName: Name 'T8_4_start' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. - PureJavaCrc32C.java:[106,28] (naming) ConstantName: Name 'T8_5_start' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. - PureJavaCrc32C.java:[107,28] (naming) ConstantName: Name 'T8_6_start' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. - PureJavaCrc32C.java:[108,28] (naming) ConstantName: Name 'T8_7_start' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. - PureJavaCrc32C.java:[112 - 630] (regexp) RegexpSingleline: Line has trailing spaces. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RATIS-416) Fix checkstyle warnings in ClientImplUtils
Tsz Wo Nicholas Sze created RATIS-416: - Summary: Fix checkstyle warnings in ClientImplUtils Key: RATIS-416 URL: https://issues.apache.org/jira/browse/RATIS-416 Project: Ratis Issue Type: Sub-task Reporter: Tsz Wo Nicholas Sze - ClientImplUtils.java:[24,8] (imports) UnusedImports: Unused import - org.apache.ratis.retry.RetryPolicies. - ClientImplUtils.java:[26,8] (imports) UnusedImports: Unused import - org.apache.ratis.util.TimeDuration. - ClientImplUtils.java:[31,1] (design) HideUtilityClassConstructor: Utility classes should not have a public or default constructor. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RATIS-415) Fix checkstyle warnings in RaftClientRpcWithProxy
Tsz Wo Nicholas Sze created RATIS-415: - Summary: Fix checkstyle warnings in RaftClientRpcWithProxy Key: RATIS-415 URL: https://issues.apache.org/jira/browse/RATIS-415 Project: Ratis Issue Type: Sub-task Reporter: Tsz Wo Nicholas Sze - RaftClientRpcWithProxy.java:[36,3] (design) DesignForExtension: Method 'getProxies' is not designed for extension - needs to be abstract, final or empty. - RaftClientRpcWithProxy.java:[40,3] (design) DesignForExtension: Method 'addServers' is not designed for extension - needs to be abstract, final or empty. - RaftClientRpcWithProxy.java:[45,3] (design) DesignForExtension: Method 'handleException' is not designed for extension - needs to be abstract, final or empty. - RaftClientRpcWithProxy.java:[50,3] (design) DesignForExtension: Method 'close' is not designed for extension - needs to be abstract, final or empty. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RATIS-414) Fix checkstyle warnings in RaftClient and RaftClientImpl
Tsz Wo Nicholas Sze created RATIS-414: - Summary: Fix checkstyle warnings in RaftClient and RaftClientImpl Key: RATIS-414 URL: https://issues.apache.org/jira/browse/RATIS-414 Project: Ratis Issue Type: Sub-task Reporter: Tsz Wo Nicholas Sze - RaftClient.java:[155,43] (coding) HiddenField: 'group' hides a field. - RaftClientImpl.java:[23,8] (imports) UnusedImports: Unused import - org.apache.ratis.retry.RetryPolicies. - RaftClientImpl.java:[45,35] (naming) ConstantName: Name 'callIdCounter' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. - RaftClientImpl.java:[237] (sizes) LineLength: Line is longer than 120 characters (found 122). - RaftClientImpl.java:[237,50] (coding) HiddenField: 'groupId' hides a field. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-413) [Umbrella] Fix checkstyle warnings
[
https://issues.apache.org/jira/browse/RATIS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687382#comment-16687382
]
Tsz Wo Nicholas Sze commented on RATIS-413:
---
The warnings can be generated by
{code}
$mvn checkstyle:checkstyle
{code}
> [Umbrella] Fix checkstyle warnings
> --
>
> Key: RATIS-413
> URL: https://issues.apache.org/jira/browse/RATIS-413
> Project: Ratis
> Issue Type: Improvement
>Reporter: Tsz Wo Nicholas Sze
>Priority: Major
>
> After RATIS-131, we should fix the legitimate checkstyle warnings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RATIS-413) [Umbrella] Fix checkstyle warnings
Tsz Wo Nicholas Sze created RATIS-413: - Summary: [Umbrella] Fix checkstyle warnings Key: RATIS-413 URL: https://issues.apache.org/jira/browse/RATIS-413 Project: Ratis Issue Type: Improvement Reporter: Tsz Wo Nicholas Sze After RATIS-131, we should fix the legitimate checkstyle warnings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-409) Watch requests may not work if there is a conf change
[ https://issues.apache.org/jira/browse/RATIS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687364#comment-16687364 ] Tsz Wo Nicholas Sze commented on RATIS-409: --- > commitIndexChanged method doesn't set ReplicationLevel.MAJORITY. ... ReplicationLevel.MAJORITY is taken care in LeaderState.updateCommit(long majority, long min). It will call ServerState.updateStatemachine(..) and then log.updateLastCommitted(..). It is the only way that the index for eplicationLevel.MAJORITY will change. > Watch requests may not work if there is a conf change > - > > Key: RATIS-409 > URL: https://issues.apache.org/jira/browse/RATIS-409 > Project: Ratis > Issue Type: Bug > Components: server >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze >Priority: Major > Attachments: r409_20181112.patch, r409_20181113.patch, > r409_20181113b.patch > > > When there is commitIndex changed, the watchRequests is updated with the > indices in SenderList. However, when there is a conf change, SenderList > includes all servers in both old and new confs. As a result, the computed > indices may be incorrect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (RATIS-386) Raft Client Async API's should honor Retry Policy
[
https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686481#comment-16686481
]
Shashikant Banerjee edited comment on RATIS-386 at 11/15/18 1:07 AM:
-
Thanks [~szetszwo] for the comments. Moving the retryPolicy Check to here :
{code:java}
private CompletableFuture sendRequestAsync( RaftClientRequest
request, intattemptCount) {
LOG.debug("{}: send* {}", clientId, request);
return clientRpc.sendRequestAsync(request).thenApply(reply -> {
LOG.info("{}: receive* {}", clientId, reply);
reply = handleNotLeaderException(request, reply);
if (reply == null) {
if (!retryPolicy.shouldRetry(attemptCount)) {
LOG.info(" fail with max attempts failed");
reply = new RaftClientReply(request, new RaftException("Failed " +
request + " for "
+ attemptCount + " attempts with " + retryPolicy), null);
}
}
if (reply != null) {
getSlidingWindow(request).receiveReply(
request.getSeqNum(), reply, this::sendRequestWithRetryAsync);
}
return reply;
}).exceptionally(e -> {
if (LOG.isTraceEnabled()) {
LOG.trace(clientId + ": Failed " + request, e);
} else {
LOG.debug("{}: Failed {} with {}", clientId, request, e);
}
e = JavaUtils.unwrapCompletionException(e);
if (e instanceof GroupMismatchException) {
throw new CompletionException(e);
} else if (e instanceof IOException) {
handleIOException(request, (IOException)e, null);
} else {
throw new CompletionException(e);
}
return null;
});
}{code}
In case, clientRpc.sendRequestAsync(request) timeout, it will execute the code
in exceptionally Path. In such case, #sendRequestWithRetryAsync will keep on
retrying calling #sendRequestAsync as the retry validation will only be
executed if clientRpc.sendRequestAsync(request) completes normally.
Also, in case the retryValidation check fails, we just return null for
RaftClientReply for the sync API here without throwing any exception:
{code:java}
private RaftClientReply sendRequestWithRetry(
Supplier supplier)
throws InterruptedIOException, StateMachineException,
GroupMismatchException {
for(int attemptCount = 0;; attemptCount++) {
final RaftClientRequest request = supplier.get();
final RaftClientReply reply = sendRequest(request);
if (reply != null) {
return reply;
}
if (!retryPolicy.shouldRetry(attemptCount)) {
return null;
}
try {
retryPolicy.getSleepTime().sleep();
} catch (InterruptedException e) {
throw new InterruptedIOException("retry policy=" + retryPolicy);
}
}
}
{code}
I think ,we probably should have same result for sync/async api's here.
Let me know if i am missing something here.
was (Author: shashikant):
Thanks [~szetszwo] for the comments. Moving the retryPolicy Check to here :
{code:java}
private CompletableFuture sendRequestWithRetryAsync(
RaftClientRequest request, intattemptCount) {
LOG.debug("{}: send* {}", clientId, request);
return clientRpc.sendRequestAsync(request).thenApply(reply -> {
LOG.info("{}: receive* {}", clientId, reply);
reply = handleNotLeaderException(request, reply);
if (reply == null) {
if (!retryPolicy.shouldRetry(attemptCount)) {
LOG.info(" fail with max attempts failed");
reply = new RaftClientReply(request, new RaftException("Failed " +
request + " for "
+ attemptCount + " attempts with " + retryPolicy), null);
}
}
if (reply != null) {
getSlidingWindow(request).receiveReply(
request.getSeqNum(), reply, this::sendRequestWithRetryAsync);
}
return reply;
}).exceptionally(e -> {
if (LOG.isTraceEnabled()) {
LOG.trace(clientId + ": Failed " + request, e);
} else {
LOG.debug("{}: Failed {} with {}", clientId, request, e);
}
e = JavaUtils.unwrapCompletionException(e);
if (e instanceof GroupMismatchException) {
throw new CompletionException(e);
} else if (e instanceof IOException) {
handleIOException(request, (IOException)e, null);
} else {
throw new CompletionException(e);
}
return null;
});
}{code}
In case, clientRpc.sendRequestAsync(request) timeout, it will execute the code
in exceptionally Path. In such case, #sendRequestWithRetryAsync will keep on
retrying calling #sendRequestAsync as the retry validation will only be
executed if clientRpc.sendRequestAsync(request) completes normally.
Also, in case the retryValidation check fails, we just return null for
RaftClientReply for the sync API here without throwing any exception:
{code:java}
private RaftClientReply sendRequestWithRetry(
Supplier supplier)
throws InterruptedIOException, StateMachineException,
GroupMismatchException {
for(int attemptCount = 0;; attemptCount++) {
final RaftClientRequest
[jira] [Commented] (RATIS-406) In RaftServerImpl, the RaftLog.append(entries) call should not hold the RaftServerImpl lock
[ https://issues.apache.org/jira/browse/RATIS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687344#comment-16687344 ] Jitendra Nath Pandey commented on RATIS-406: +1 for the patch. > In RaftServerImpl, the RaftLog.append(entries) call should not hold the > RaftServerImpl lock > --- > > Key: RATIS-406 > URL: https://issues.apache.org/jira/browse/RATIS-406 > Project: Ratis > Issue Type: Improvement > Components: server >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze >Priority: Major > Attachments: r406_20181109.patch, r406_20181113.patch, > r406_20181114.patch > > > In RaftServerImpl, the appendEntriesAsync(..) calls must be sequential > (although the actual log I/O is async). Otherwise, the entries appended may > be out of order. > As a result, RaftLog.append(entries) needs not to hold the RaftServerImpl > lock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-409) Watch requests may not work if there is a conf change
[
https://issues.apache.org/jira/browse/RATIS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687343#comment-16687343
]
Jitendra Nath Pandey commented on RATIS-409:
{{commitIndexChanged}} method doesn't set \{{ReplicationLevel.MAJORITY}}. It
seems in some code paths, MAJORITY is not being set at all.
> Watch requests may not work if there is a conf change
> -
>
> Key: RATIS-409
> URL: https://issues.apache.org/jira/browse/RATIS-409
> Project: Ratis
> Issue Type: Bug
> Components: server
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
>Priority: Major
> Attachments: r409_20181112.patch, r409_20181113.patch,
> r409_20181113b.patch
>
>
> When there is commitIndex changed, the watchRequests is updated with the
> indices in SenderList. However, when there is a conf change, SenderList
> includes all servers in both old and new confs. As a result, the computed
> indices may be incorrect.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RATIS-406) In RaftServerImpl, the RaftLog.append(entries) call should not hold the RaftServerImpl lock
[
https://issues.apache.org/jira/browse/RATIS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687220#comment-16687220
]
Hadoop QA commented on RATIS-406:
-
| (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: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} @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} 2m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
41s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
0m 16s{color} | {color:orange} root: The patch generated 8 new + 101 unchanged
- 13 fixed = 109 total (was 114) {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} javadoc {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 18m 47s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 26m 45s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | ratis.grpc.TestRaftStateMachineExceptionWithGrpc |
| | ratis.server.simulation.TestRaftReconfigurationWithSimulatedRpc |
| | ratis.server.simulation.TestLeaderElectionWithSimulatedRpc |
| | ratis.server.simulation.TestServerRestartWithSimulatedRpc |
| | ratis.server.simulation.TestRaftWithSimulatedRpc |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/ratis:date2018-11-14
|
| JIRA Issue | RATIS-406 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12948211/r406_20181114.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
checkstyle compile |
| uname | Linux cdceea363cc5 3.13.0-153-generic #203-Ubuntu SMP Thu Jun 14
08:52:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-RATIS-Build/yetus-personality.sh
|
| git revision | master / 16cadb6 |
| maven | version: Apache Maven 3.6.0
(97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T18:41:47Z) |
| Default Java | 1.8.0_181 |
| checkstyle |
https://builds.apache.org/job/PreCommit-RATIS-Build/521/artifact/out/diff-checkstyle-root.txt
|
| unit |
https://builds.apache.org/job/PreCommit-RATIS-Build/521/artifact/out/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-RATIS-Build/521/testReport/ |
| Max. process+thread count | 3232 (vs. ulimit of 5000) |
| modules | C: ratis-server U: ratis-server |
| Console output |
https://builds.apache.org/job/PreCommit-RATIS-Build/521/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> In RaftServerImpl, the RaftLog.append(entries) call should not hold the
> RaftServerImpl lock
>
[jira] [Commented] (RATIS-131) Add checkstyle configuration
[ https://issues.apache.org/jira/browse/RATIS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687145#comment-16687145 ] Jitendra Nath Pandey commented on RATIS-131: +1 > Add checkstyle configuration > > > Key: RATIS-131 > URL: https://issues.apache.org/jira/browse/RATIS-131 > Project: Ratis > Issue Type: Bug > Components: build >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze >Priority: Major > Attachments: r131_20181113.patch, r131_20181113b.patch > > > This JIRA is to setup our checkstyle coding conventions. We probably should > start with [Sun coding > conventions|https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/sun_checks.xml] > or [Google coding > conventions|https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-386) Raft Client Async API's should honor Retry Policy
[ https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687040#comment-16687040 ] Tsz Wo Nicholas Sze commented on RATIS-386: --- > I think ,we probably should have same result for sync/async api's here. That's is good point. We should change the sync case to throw the same exception then. In the 000 patch, the sync case we get null but the asyn case will get TimeoutException. > Raft Client Async API's should honor Retry Policy > -- > > Key: RATIS-386 > URL: https://issues.apache.org/jira/browse/RATIS-386 > Project: Ratis > Issue Type: Improvement > Components: client >Affects Versions: 0.3.0 >Reporter: Shashikant Banerjee >Assignee: Shashikant Banerjee >Priority: Major > Fix For: 0.3.0 > > Attachments: RATIS-386.000.patch > > > Raft client sync Api has support for retry policies. Similarly, for Async > API's including watch Api, support for Retry Policy is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-406) In RaftServerImpl, the RaftLog.append(entries) call should not hold the RaftServerImpl lock
[ https://issues.apache.org/jira/browse/RATIS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687033#comment-16687033 ] Tsz Wo Nicholas Sze commented on RATIS-406: --- > ... I think instead of blocking the thread we should just fail the operation. > ... In such a case we can safely include the append entries inside the lock > by making sure it does not block the thread? Failing the operation is worth to consider. However, it still gives a better performance if we can avoid the lock. The deadlock bug is already fixed by RATIS-404. Here, we just want to improve the performance. > I think we can get rid of the lock on RaftServerImpl in latter part of the > function. We take a lock for updating the state machine. It is possible. Let me think about it but I would rather do it in a separate JIRA. > In RaftServerImpl, the RaftLog.append(entries) call should not hold the > RaftServerImpl lock > --- > > Key: RATIS-406 > URL: https://issues.apache.org/jira/browse/RATIS-406 > Project: Ratis > Issue Type: Improvement > Components: server >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze >Priority: Major > Attachments: r406_20181109.patch, r406_20181113.patch > > > In RaftServerImpl, the appendEntriesAsync(..) calls must be sequential > (although the actual log I/O is async). Otherwise, the entries appended may > be out of order. > As a result, RaftLog.append(entries) needs not to hold the RaftServerImpl > lock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-406) In RaftServerImpl, the RaftLog.append(entries) call should not hold the RaftServerImpl lock
[ https://issues.apache.org/jira/browse/RATIS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687014#comment-16687014 ] Tsz Wo Nicholas Sze commented on RATIS-406: --- > ... Would it be simpler to either force only one thread can call it, or just > use a dedicated lock instead of using RaftServerImpl lock? This patch is to enforce that only one thread can call it - runSequentially does nothing but only an assertion (asserting only at most one thread at a time.) runSequentially is to prove that moving RaftLog.append(entries) outside the RaftServerImpl is correct (otherwise, we will get IllegalStateException.) Using a lock does not work since if two threads are waiting, the order is not guaranteed. Do you see another way to enforce it? > In RaftServerImpl, the RaftLog.append(entries) call should not hold the > RaftServerImpl lock > --- > > Key: RATIS-406 > URL: https://issues.apache.org/jira/browse/RATIS-406 > Project: Ratis > Issue Type: Improvement > Components: server >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze >Priority: Major > Attachments: r406_20181109.patch, r406_20181113.patch > > > In RaftServerImpl, the appendEntriesAsync(..) calls must be sequential > (although the actual log I/O is async). Otherwise, the entries appended may > be out of order. > As a result, RaftLog.append(entries) needs not to hold the RaftServerImpl > lock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-406) In RaftServerImpl, the RaftLog.append(entries) call should not hold the RaftServerImpl lock
[
https://issues.apache.org/jira/browse/RATIS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686937#comment-16686937
]
Lokesh Jain commented on RATIS-406:
---
[~szetszwo] Thanks for working on this! I had a few thoughts on
RaftServerImpl#appendEntriesAsync.
# RaftLogWorker uses a blocking queue which blocks the thread in addIOTask
function if queue is full. I think instead of blocking the thread we should
just fail the operation. RaftLogWorker#addIOTask is invoked via appendEntry
call.
{code:java}
futures = state.getLog().append(entries);
{code}
In such a case we can safely include the append entries inside the lock by
making sure it does not block the thread?
# I think we can get rid of the lock on RaftServerImpl in latter part of the
function. We take a lock for updating the state machine.
> In RaftServerImpl, the RaftLog.append(entries) call should not hold the
> RaftServerImpl lock
> ---
>
> Key: RATIS-406
> URL: https://issues.apache.org/jira/browse/RATIS-406
> Project: Ratis
> Issue Type: Improvement
> Components: server
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
>Priority: Major
> Attachments: r406_20181109.patch, r406_20181113.patch
>
>
> In RaftServerImpl, the appendEntriesAsync(..) calls must be sequential
> (although the actual log I/O is async). Otherwise, the entries appended may
> be out of order.
> As a result, RaftLog.append(entries) needs not to hold the RaftServerImpl
> lock.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RATIS-386) Raft Client Async API's should honor Retry Policy
[
https://issues.apache.org/jira/browse/RATIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686481#comment-16686481
]
Shashikant Banerjee commented on RATIS-386:
---
Thanks [~szetszwo] for the comments. Moving the retryPolicy Check to here :
{code:java}
private CompletableFuture sendRequestWithRetryAsync(
RaftClientRequest request, intattemptCount) {
LOG.debug("{}: send* {}", clientId, request);
return clientRpc.sendRequestAsync(request).thenApply(reply -> {
LOG.info("{}: receive* {}", clientId, reply);
reply = handleNotLeaderException(request, reply);
if (reply == null) {
if (!retryPolicy.shouldRetry(attemptCount)) {
LOG.info(" fail with max attempts failed");
reply = new RaftClientReply(request, new RaftException("Failed " +
request + " for "
+ attemptCount + " attempts with " + retryPolicy), null);
}
}
if (reply != null) {
getSlidingWindow(request).receiveReply(
request.getSeqNum(), reply, this::sendRequestWithRetryAsync);
}
return reply;
}).exceptionally(e -> {
if (LOG.isTraceEnabled()) {
LOG.trace(clientId + ": Failed " + request, e);
} else {
LOG.debug("{}: Failed {} with {}", clientId, request, e);
}
e = JavaUtils.unwrapCompletionException(e);
if (e instanceof GroupMismatchException) {
throw new CompletionException(e);
} else if (e instanceof IOException) {
handleIOException(request, (IOException)e, null);
} else {
throw new CompletionException(e);
}
return null;
});
}{code}
In case, clientRpc.sendRequestAsync(request) timeout, it will execute the code
in exceptionally Path. In such case, #sendRequestWithRetryAsync will keep on
retrying calling #sendRequestAsync as the retry validation will only be
executed if clientRpc.sendRequestAsync(request) completes normally.
Also, in case the retryValidation check fails, we just return null for
RaftClientReply for the sync API here without throwing any exception:
{code:java}
private RaftClientReply sendRequestWithRetry(
Supplier supplier)
throws InterruptedIOException, StateMachineException,
GroupMismatchException {
for(int attemptCount = 0;; attemptCount++) {
final RaftClientRequest request = supplier.get();
final RaftClientReply reply = sendRequest(request);
if (reply != null) {
return reply;
}
if (!retryPolicy.shouldRetry(attemptCount)) {
return null;
}
try {
retryPolicy.getSleepTime().sleep();
} catch (InterruptedException e) {
throw new InterruptedIOException("retry policy=" + retryPolicy);
}
}
}
{code}
I think ,we probably should have same result for sync/async api's here.
Let me know if i am missing something here.
> Raft Client Async API's should honor Retry Policy
> --
>
> Key: RATIS-386
> URL: https://issues.apache.org/jira/browse/RATIS-386
> Project: Ratis
> Issue Type: Improvement
> Components: client
>Affects Versions: 0.3.0
>Reporter: Shashikant Banerjee
>Assignee: Shashikant Banerjee
>Priority: Major
> Fix For: 0.3.0
>
> Attachments: RATIS-386.000.patch
>
>
> Raft client sync Api has support for retry policies. Similarly, for Async
> API's including watch Api, support for Retry Policy is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
