You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ratis.apache.org by "Siddharth Wagle (JIRA)" <ji...@apache.org> on 2019/06/17 18:31:00 UTC

[jira] [Updated] (RATIS-592) One node ratis writes fail forever after first NotLeaderException or LeaderNotReadyException

     [ https://issues.apache.org/jira/browse/RATIS-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Siddharth Wagle updated RATIS-592:
----------------------------------
    Summary: One node ratis writes fail forever after first NotLeaderException or LeaderNotReadyException  (was: One node ratis writes fail after first NotLeaderException or LeaderNotReadyException)

> One node ratis writes fail forever after first NotLeaderException or LeaderNotReadyException
> --------------------------------------------------------------------------------------------
>
>                 Key: RATIS-592
>                 URL: https://issues.apache.org/jira/browse/RATIS-592
>             Project: Ratis
>          Issue Type: Bug
>          Components: gRPC
>    Affects Versions: 0.3.0
>            Reporter: Siddharth Wagle
>            Assignee: Siddharth Wagle
>            Priority: Critical
>             Fix For: 0.4.0
>
>
> RATIS-571, modified the GrpcClientProtocolClient to not set the AsyncStreamObserver reference to null on an exception, however, the ReplyMap reference is set to null. This results in the client getting an AlredyClosedException on the stream on a retry for a NotLeader or a LeadrNotReady exception and never recovers. This is common in a unit test scenario where a request is sent immediately after the cluster is up.
> There is nothing special here about one node Ratis however, the HDDS unit tests that fail are all one node Ratis and the most probable cause is that with client retrying a different node each time, increases the chance of success on a three-node ring.



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