[
https://issues.apache.org/jira/browse/RATIS-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868881#comment-16868881
]
Siddharth Wagle edited comment on RATIS-592 at 6/20/19 8:09 PM:
----------------------------------------------------------------
Thanks for the comments, Lokesh.
1. Made the change to return reply with an exception on LeaderNotReady.
2. In one node Ratis ideally we should never throw NotLeaderException, rather
it should be LeaderNotReady. cc: [~szetszwo]
For now, I made the simple change to make sure we retry in NotLeader on one
node Ratis.
Verified candidate unit tests pass in HDDS.
was (Author: swagle):
Thanks for the comments, Lokesh.
1. Made the change to return reply with an exception on LeaderNotReady.
2. In one node Ratis ideally we should never throw NotLeaderException, rather
it should be LeaderNotReady. cc: [~szetszwo]
For now, I made the simple change to make sure we retry in NotLeader on one
node Ratis.
> 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
>
> Attachments: RATIS-592.01.patch, RATIS-592.02.patch
>
>
> 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)