[ 
https://issues.apache.org/jira/browse/RATIS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16829586#comment-16829586
 ] 

Hadoop QA commented on RATIS-458:
---------------------------------

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  3s{color} 
| {color:red} RATIS-458 does not apply to master. Rebase required? Wrong 
Branch? See https://yetus.apache.org/documentation/0.8.0/precommit-patchnames 
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | RATIS-458 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12955384/RATIS-458.003.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-RATIS-Build/744/console |
| Powered by | Apache Yetus 0.8.0   http://yetus.apache.org |


This message was automatically generated.



> GrpcLogAppender#shouldWait should wait on pending log entries to follower
> -------------------------------------------------------------------------
>
>                 Key: RATIS-458
>                 URL: https://issues.apache.org/jira/browse/RATIS-458
>             Project: Ratis
>          Issue Type: Bug
>            Reporter: Lokesh Jain
>            Assignee: Lokesh Jain
>            Priority: Major
>         Attachments: RATIS-458.001.patch, RATIS-458.002.patch, 
> RATIS-458.003.patch
>
>
> In GrpcLogAppender when an append entry times out we remove the entry from 
> the pendingRequests. This decreases the size of pendingRequests which affects 
> the logic in GrpcLogAppender#shouldWait. Further we also consider heartbeats 
> in shouldWait because heartbeats are tracked in pendingRequests. It should 
> actually wait on the number of log entries which are appended to follower but 
> have not yet been processed by it.
> GrpcConfigKeys.Server.leaderOutstandingAppendsMax should also be a fraction 
> of RaftServerConfigKeys.Log.queueSize. This brings flow control for leader's 
> append entries to follower because then number of outstanding append entries 
> in leader would be limited by maximum number of operations in raft log worker.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to