-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Heartbeat does not respond to timeout while waiting for a response from the server #268
Comments
Looks like you've found a bug. Indeed we neglect to deal with the return value of the await() call. On second thought, I have the impression this change in this class should just be rolled back. It has no benefit at all. |
@tomaswolf can you explain in more detail please? Did I understand correctly that you are proposing to roll back and generally refuse to wait for a response to a heartbeat? Are there any disadvantages or fundamental errors in the solution proposed by @robober? Is it correct in principle to wait response to every heartbeat? |
Yes.
No. Seems to me that rolling back would use the synchronous
No. But looking back at this code, I don't see anymore why I even changed it. Using the asynchronous global request but then waiting on the latch is still blocking of course. But heartbeats are sent from separate threads anyway, so this doesn't block an I/O thread. |
Thank you for explanation. In this case, we will use our modified heartbeat for a while, waiting for fix in library. |
If a reply is requested, but none arrives within the timeout, throw an exception and terminate the connection. This rolls back the changes made in ClientConnectionService in commit de2f8fe. It's quite all right to use the synchronous implementation of Session.request() because heartbeats are not sent from I/O threads. Bug: apache#268
If a reply is requested, but none arrives within the timeout, throw an exception and terminate the connection. This rolls back the changes made in ClientConnectionService in commit de2f8fe. It's quite all right to use the synchronous implementation of Session.request() because heartbeats are not sent from I/O threads. However, commit de2f8fe broke the contract specified in interface Session, which says Session.request() must return "the buffer if the request was successful, {@code null} otherwise." The implementation from commit de2f8fe threw an exception instead. This was wrong, and is corrected now in this commit. Note that this means that a caller cannot distinguish between the server replying SSH_MSG_UNIMPLEMENTED or SSH_MSG_REQUEST_FAILURE. Where such distinction is needed, use an asynchronous global request instead. Bug: apache#268
If heartbeat is waiting for a response from the server and the response did not come within the allotted time, then we must kill the session because the server is not responding, in which case the lack of response to waiting for a response in
org.apache.sshd.client.session.ClientConnectionService#sendHeartBeat
looks like wrong behavior.Should we do something like
if (!replyReceived.await(toWait, TimeUnit.MILLISECONDS)) { throw new TimeoutException("No response from server"); }
when waiting response on heartbeat request
Am I understanding heartbeat logic correctly?
The text was updated successfully, but these errors were encountered: