[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=16690216#comment-16690216
]
Hadoop QA commented on RATIS-409:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{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
22s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
45s{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
5s{color} | {color:blue} Maven dependency ordering for patch {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
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
0m 13s{color} | {color:orange} root: The patch generated 4 new + 25 unchanged -
1 fixed = 29 total (was 26) {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
31s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 11m 51s{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 52s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | ratis.grpc.TestRaftAsyncWithGrpc |
| | ratis.netty.TestRaftReconfigurationWithNetty |
| | ratis.server.simulation.TestRaftReconfigurationWithSimulatedRpc |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/ratis:date2018-11-17
|
| JIRA Issue | RATIS-409 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12948579/r409_20181116.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
checkstyle compile |
| uname | Linux 59ce06fe3093 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 / 5b8bbee |
| 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/535/artifact/out/diff-checkstyle-root.txt
|
| unit |
https://builds.apache.org/job/PreCommit-RATIS-Build/535/artifact/out/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-RATIS-Build/535/testReport/ |
| Max. process+thread count | 3038 (vs. ulimit of 5000) |
| modules | C: ratis-common ratis-server ratis-grpc U: . |
| Console output |
https://builds.apache.org/job/PreCommit-RATIS-Build/535/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Watch requests may not work if there is a conf change
> -
>
> Key: RATIS-409
>
[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=16690214#comment-16690214 ] Tsz Wo Nicholas Sze commented on RATIS-409: --- r409_20181116.patch: refactors the log index change code so that the expectation is more clear. > 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, r409_20181115.patch, r409_20181116.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] [Updated] (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:all-tabpanel ] Tsz Wo Nicholas Sze updated RATIS-409: -- Attachment: r409_20181116.patch > 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, r409_20181115.patch, r409_20181116.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-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=16690192#comment-16690192 ] Tsz Wo Nicholas Sze commented on RATIS-409: --- > ... commitIndex should be updated using max. The reason of using max is that follower may create replies out of order for both heartbeats and normal appendEntries. Since the commit index is retrieved from RaftLog in follower, it is correct that leader simply uses max to update the commit index for the particular follower. > 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, r409_20181115.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] [Updated] (RATIS-428) Phi accrual failure detector
[ https://issues.apache.org/jira/browse/RATIS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated RATIS-428: Description: Failure detectors are an important piece in designing robust distributed systems. Components must be expected to fail, and the rest of the system should either continue functioning properly (ideal) or at the very least degrade gracefully instead of crashing or becoming corrupted. Because of the unreliable nature of communication over networks, however, detecting that a node has failed is a nontrivial task. The *phi accrual failure detector* is a popular choice for solving this problem, as it provides a good balance of flexibility and adaptability to different network conditions. It is used successfully in several real-world distributed systems, such as Apache Cassandra (see here) and Akka clusters (see here), and also has a Node.js implementation. [Original paper|http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.7427=rep1=pdf] was: Failure detectors are an important piece in designing robust distributed systems. Components must be expected to fail, and the rest of the system should either continue functioning properly (ideal) or at the very least degrade gracefully instead of crashing or becoming corrupted. Because of the unreliable nature of communication over networks, however, detecting that a node has failed is a nontrivial task. The *phi accrual failure detector* is a popular choice for solving this problem, as it provides a good balance of flexibility and adaptability to different network conditions. It is used successfully in several real-world distributed systems, such as Apache Cassandra (see here) and Akka clusters (see here), and also has a Node.js implementation. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.7427=rep1=pdf|Original paper] > Phi accrual failure detector > > > Key: RATIS-428 > URL: https://issues.apache.org/jira/browse/RATIS-428 > Project: Ratis > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Major > > Failure detectors are an important piece in designing robust distributed > systems. Components must be expected to fail, and the rest of the system > should either continue functioning properly (ideal) or at the very least > degrade gracefully instead of crashing or becoming corrupted. Because of the > unreliable nature of communication over networks, however, detecting that a > node has failed is a nontrivial task. The *phi accrual failure detector* is a > popular choice for solving this problem, as it provides a good balance of > flexibility and adaptability to different network conditions. It is used > successfully in several real-world distributed systems, such as Apache > Cassandra (see here) and Akka clusters (see here), and also has a Node.js > implementation. > [Original > paper|http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.7427=rep1=pdf] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RATIS-428) Phi accrual failure detector
[ https://issues.apache.org/jira/browse/RATIS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated RATIS-428: Description: Failure detectors are an important piece in designing robust distributed systems. Components must be expected to fail, and the rest of the system should either continue functioning properly (ideal) or at the very least degrade gracefully instead of crashing or becoming corrupted. Because of the unreliable nature of communication over networks, however, detecting that a node has failed is a nontrivial task. The *phi accrual failure detector* is a popular choice for solving this problem, as it provides a good balance of flexibility and adaptability to different network conditions. It is used successfully in several real-world distributed systems, such as Apache Cassandra (see here) and Akka clusters (see here), and also has a Node.js implementation. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.7427=rep1=pdf|Original paper] was:Failure detectors are an important piece in designing robust distributed systems. Components must be expected to fail, and the rest of the system should either continue functioning properly (ideal) or at the very least degrade gracefully instead of crashing or becoming corrupted. Because of the unreliable nature of communication over networks, however, detecting that a node has failed is a nontrivial task. The *phi accrual failure detector* is a popular choice for solving this problem, as it provides a good balance of flexibility and adaptability to different network conditions. It is used successfully in several real-world distributed systems, such as Apache Cassandra (see here) and Akka clusters (see here), and also has a Node.js implementation. > Phi accrual failure detector > > > Key: RATIS-428 > URL: https://issues.apache.org/jira/browse/RATIS-428 > Project: Ratis > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Major > > Failure detectors are an important piece in designing robust distributed > systems. Components must be expected to fail, and the rest of the system > should either continue functioning properly (ideal) or at the very least > degrade gracefully instead of crashing or becoming corrupted. Because of the > unreliable nature of communication over networks, however, detecting that a > node has failed is a nontrivial task. The *phi accrual failure detector* is a > popular choice for solving this problem, as it provides a good balance of > flexibility and adaptability to different network conditions. It is used > successfully in several real-world distributed systems, such as Apache > Cassandra (see here) and Akka clusters (see here), and also has a Node.js > implementation. > [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.7427=rep1=pdf|Original > paper] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RATIS-428) Phi accrual failure detector
Vladimir Rodionov created RATIS-428: --- Summary: Phi accrual failure detector Key: RATIS-428 URL: https://issues.apache.org/jira/browse/RATIS-428 Project: Ratis Issue Type: Improvement Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov Failure detectors are an important piece in designing robust distributed systems. Components must be expected to fail, and the rest of the system should either continue functioning properly (ideal) or at the very least degrade gracefully instead of crashing or becoming corrupted. Because of the unreliable nature of communication over networks, however, detecting that a node has failed is a nontrivial task. The *phi accrual failure detector* is a popular choice for solving this problem, as it provides a good balance of flexibility and adaptability to different network conditions. It is used successfully in several real-world distributed systems, such as Apache Cassandra (see here) and Akka clusters (see here), and also has a Node.js implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-415) Disable checkstyle DesignForExtension rule
[ https://issues.apache.org/jira/browse/RATIS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690023#comment-16690023 ] Jitendra Nath Pandey commented on RATIS-415: +1 > 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 > Attachments: r415_20181115.patch > > > 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] [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 ] Tsz Wo Nicholas Sze updated RATIS-386: -- Attachment: RATIS-386.004_committed.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, RATIS-386.002.patch, > RATIS-386.003.patch, RATIS-386.004.patch, RATIS-386.004_committed.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] [Resolved] (RATIS-309) Add client api's to add/remove peers from a raft group.
[ https://issues.apache.org/jira/browse/RATIS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo Nicholas Sze resolved RATIS-309. --- Resolution: Not A Problem Resolving this as Not-A-Problem. > Add client api's to add/remove peers from a raft group. > --- > > Key: RATIS-309 > URL: https://issues.apache.org/jira/browse/RATIS-309 > Project: Ratis > Issue Type: Bug > Components: server >Reporter: Mukul Kumar Singh >Assignee: Tsz Wo Nicholas Sze >Priority: Major > > Even though Ratis server provides api's to add remove peers from a raft > server, there are no client side api's to let us do the same. -- 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=16689914#comment-16689914 ] Tsz Wo Nicholas Sze commented on RATIS-386: --- +1 the 004 patch looks good. - ./ratis-common/src/main/java/org/apache/ratis/protocol/RaftRetryFailureException.java:20:import org.apache.ratis.retry.RetryPolicy;:8: Unused import - org.apache.ratis.retry.RetryPolicy. [UnusedImports] - ./ratis-grpc/src/main/java/org/apache/ratis/grpc/GrpcConfigKeys.java:20:import org.apache.ratis.client.RaftClientConfigKeys;:8: Unused import - org.apache.ratis.client.RaftClientConfigKeys. [UnusedImports] There are two unused imports. Please remove them while committing. Thanks, [~shashikant]! > 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, > RATIS-386.003.patch, RATIS-386.004.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-427) Add doesGroupExists API to RaftServer
[
https://issues.apache.org/jira/browse/RATIS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689846#comment-16689846
]
Tsz Wo Nicholas Sze commented on RATIS-427:
---
We already have
- getGroupIds() in RaftServer for local clients; and
- getGroupList()/getGroupListAsync() for remote clients in
AdminProtocol/AdminAsynchronousProtocol.
So, it is easy to tell if a group exist.
> Add doesGroupExists API to RaftServer
> -
>
> Key: RATIS-427
> URL: https://issues.apache.org/jira/browse/RATIS-427
> Project: Ratis
> Issue Type: Improvement
> Components: server
>Reporter: Nanda kumar
>Priority: Major
>
> It would be very helpful to have {{doesGroupExists}} API as part of
> RaftServer, this will help us in knowing whether the RaftServer is part of
> the given group or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RATIS-426) StateMachine should be notified about index updates when confentry/no op entries are processed
[
https://issues.apache.org/jira/browse/RATIS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689452#comment-16689452
]
Hadoop QA commented on RATIS-426:
-
| (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: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
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
56s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s{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} javadoc {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 11m 0s{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 40s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | ratis.grpc.TestRaftAsyncWithGrpc |
| | ratis.grpc.TestWatchRequestWithGrpc |
| | ratis.netty.TestServerRestartWithNetty |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/ratis:date2018-11-16
|
| JIRA Issue | RATIS-426 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12948499/RATIS-426.001.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
checkstyle compile |
| uname | Linux 9669c1492be5 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 / a0f19ce |
| maven | version: Apache Maven 3.6.0
(97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T18:41:47Z) |
| Default Java | 1.8.0_181 |
| unit |
https://builds.apache.org/job/PreCommit-RATIS-Build/534/artifact/out/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-RATIS-Build/534/testReport/ |
| Max. process+thread count | 2707 (vs. ulimit of 5000) |
| modules | C: ratis-server U: ratis-server |
| Console output |
https://builds.apache.org/job/PreCommit-RATIS-Build/534/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> StateMachine should be notified about index updates when confentry/no op
> entries are processed
> --
>
> Key: RATIS-426
> URL: https://issues.apache.org/jira/browse/RATIS-426
> Project: Ratis
> Issue Type: Bug
> Components: server
>Reporter: Mukul Kumar Singh
>Assignee: Mukul Kumar Singh
>Priority: Major
> Attachments: RATIS-426.001.patch
[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=16689431#comment-16689431
]
Shashikant Banerjee commented on RATIS-386:
---
The following tests fail with/without patch in my local setup intermittently.
The test failures reported are not related to the patch.
{code:java}
Failures:
[ERROR]
TestRaftReconfigurationWithGrpc>RaftReconfigurationBaseTest.testKillLeaderDuringReconf:387
[ERROR]
TestWatchRequestWithGrpc>WatchRequestTests.testWatchRequestAsync:70->WatchRequestTests.runTest:147->WatchRequestTests.runTestWatchRequestAsync:259->WatchRequestTests.lambda$runTestWatchRequestAsync$3:259
[ERROR]
TestWatchRequestWithGrpc>WatchRequestTests.testWatchRequestAsyncChangeLeader:286->WatchRequestTests.runTest:147->WatchRequestTests.runTestWatchRequestAsyncChangeLeader:338->WatchRequestTests.lambda$runTestWatchRequestAsyncChangeLeader$5:338
[ERROR]
TestRaftReconfigurationWithNetty>RaftReconfigurationBaseTest.testKillLeaderDuringReconf:387
[ERROR]
TestRaftReconfigurationWithSimulatedRpc>RaftReconfigurationBaseTest.testKillLeaderDuringReconf:387
[ERROR] Errors:
[ERROR] TestRaftAsyncWithGrpc.testStaleReadAsync » Completion
org.apache.ratis.protoco...
[INFO]
[ERROR] Tests run: 198, Failures: 5, Errors: 1, Skipped: 2
{code}
> 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,
> RATIS-386.003.patch, RATIS-386.004.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-426) StateMachine should be notified about index updates when confentry/no op entries are processed
[
https://issues.apache.org/jira/browse/RATIS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Kumar Singh updated RATIS-426:
Attachment: RATIS-426.001.patch
> StateMachine should be notified about index updates when confentry/no op
> entries are processed
> --
>
> Key: RATIS-426
> URL: https://issues.apache.org/jira/browse/RATIS-426
> Project: Ratis
> Issue Type: Bug
> Components: server
>Reporter: Mukul Kumar Singh
>Assignee: Mukul Kumar Singh
>Priority: Major
> Attachments: RATIS-426.001.patch
>
>
> In Ratis, 2 types of log entries exists, it can either of type
> StateMachineLogEntryProto or RaftConfigurationProto. Only
> StateMachineLogEntryProto is processed by the state machine, however
> RaftConfigurationProto is processed internally. In certain cases, state
> machine might like to maintain the sequence of events being processed by it
> i.e. ContainerStateMachine for Ozone. In such cases State machine should be
> notified of index updates while processing RaftConfigurationProto.
> {code}
> oneof LogEntryBody {
> StateMachineLogEntryProto stateMachineLogEntry = 3;
> RaftConfigurationProto configurationEntry = 4;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RATIS-427) Add doesGroupExists API to RaftServer
Nanda kumar created RATIS-427:
-
Summary: Add doesGroupExists API to RaftServer
Key: RATIS-427
URL: https://issues.apache.org/jira/browse/RATIS-427
Project: Ratis
Issue Type: Improvement
Components: server
Reporter: Nanda kumar
It would be very helpful to have {{doesGroupExists}} API as part of RaftServer,
this will help us in knowing whether the RaftServer is part of the given group
or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
