Skip to content

Conversation

@szetszwo
Copy link
Contributor

@szetszwo szetszwo requested a review from guohao-rosicky April 10, 2024 23:40
}

final TimeDuration timeout = isClose ? closeTimeout : requestTimeout;
replyEntry.scheduleTimeout(() -> channel.eventLoop().schedule(() -> {
Copy link
Contributor

@guohao-rosicky guohao-rosicky Apr 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @szetszwo work on this. I think about this part of the code like this:

After the client sends successfully, then wait for the server's reply, the timeout time is to detect the timeout of the server's reply, so I start the timeout listener after the client sends the request successfully. So I started the timeout listener after the client sent the request successfully, and canceled the timeout listener after the server replyed successfully.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Then, let's keep the previous logic.

@guohao-rosicky
Copy link
Contributor

+1 LGTM.

@guohao-rosicky guohao-rosicky merged commit 49b4006 into apache:master Apr 12, 2024
@szetszwo
Copy link
Contributor Author

@guohao-rosicky , thanks a lot for reviewing and merging this!

symious pushed a commit to symious/ratis that referenced this pull request Apr 16, 2024
…RemoteWrite. (apache#1064)

* RATIS-1504. Add timeout handling to DataStreamManagement#checkSuccessRemoteWrite.
szetszwo added a commit to szetszwo/ratis that referenced this pull request Jun 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants