-
Notifications
You must be signed in to change notification settings - Fork 40
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
Connection resumption improvements #900
Connection resumption improvements #900
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those changes make sense, but keep in my mind my relatively small ably-java knowledge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments inline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see inline comments.
I suggest please that we tidy this and remove the whitespace-related commits, because the commit history is now a mess.
And we still need tests pls.
0494dfd
to
34a6826
Compare
34a6826
to
d7a7081
Compare
Sorry about this, this should be clearer now - I squashed commits that were causing that
I have not finished addressing everything yet sorry. I should request for another review when I'm done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see inline comments
lib/src/test/java/io/ably/lib/test/realtime/RealtimeResumeTest.java
Outdated
Show resolved
Hide resolved
lib/src/test/java/io/ably/lib/test/realtime/RealtimeResumeTest.java
Outdated
Show resolved
Hide resolved
lib/src/test/java/io/ably/lib/test/realtime/RealtimeResumeTest.java
Outdated
Show resolved
Hide resolved
lib/src/test/java/io/ably/lib/test/realtime/RealtimeResumeTest.java
Outdated
Show resolved
Hide resolved
lib/src/test/java/io/ably/lib/test/realtime/RealtimeResumeTest.java
Outdated
Show resolved
Hide resolved
lib/src/test/java/io/ably/lib/test/realtime/RealtimeResumeTest.java
Outdated
Show resolved
Hide resolved
64ce58f
to
a1ee4ba
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good.
Can you please tidy the commit history before merging this please?
This is the first commit that addresses connection resumption issues by picking and adapting some changes from #842 This change only apply channel reattachment and overrides the previous behaviour where pending messages were suspended if a new connection was established with a non-fatal error.
This commit makes resume case explicit by isolating it into a single if branch. There were also some comments left by Paddy which I thought will be useful to keep in codebase.
a1ee4ba
to
e46d8a5
Compare
When sending messages, the reattempted messages from pending queue would be readded because sendImpl will push a new message to the queue if ack is required. This change clones previous messages from pending queue, using it as a reference to reattempt, but clears queue before reattempt. So now how it works: If the connection resumed successfully, pending messages (if available) will be added in front of queued messages, resetting the start serial to the first serial of pending messages. If connection resume is not successful, msgSerial and start serial will be reset to 0. This will also remove the explicit call to send() as the send should happen when the connection transition event arrives which should happen after this. Please note that I kept msgSerial = 0 as this will be increased in sendImpl
Message serials are now reset based on whether the connection resume succeeded or failed. In case of success, the message serial will be reset to the first serial of pending messages and in case of failure that serial will be reset to 0, the same applies to start serial in pending message queue
MockWebSocketTransport and WebSocket transport have send() but not receive() functionality, That's why we are unable to allow / block or fail incoming messages. In this commit I add a receiver interface that routes received protocol messages to websocket transport. as a result connectionManager.onMessage call moves to WebSocketTransport and as a result we can use the mock to set rules for receives. There is also a simple receive behaviour on MockWebSocketTransport that should allow us to define the same rules for receives as sends. Also MockWebSocketTransport is now public and has a new instance publishedMessages that allows us assert internals / orders of those published messages. Two tests testing the pending message behaviour : The first one is when the resume is successful and the second one is when the resume has failed
e46d8a5
to
07ad898
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've not looked at the code but see you already had two others do that. Instead, I checked out this branch, built it and integrated it with AAT to rerun the NetworkingConnectivityTest
. I can confirm that this fixes the following fault simulations:
DisconnectWithFailedResume
EnterUnresponsive
For those two, it'd be good to re-enable those tests when you integrate this release to AAT, to confirm they're green on main
too.
It also fixes the problems initially causing ReenterOnResumeFailed
to fail, leaving us now with just a non-fatal NACK
causing an exception to be thrown - a separate known issue, so we can't re-enable that test until the fix comes it.
Nice work!
This PR introduces some fixes to connection resumption issues by implementing spec RTN15c1, RTN15c2 and RTN15c3. To summarize the rule of implementation.
Previously when there was a new connection established, channels were suspended and pending messages were reset. This should not be happening anymore
Also I have made some changes to general interface of
WebSocketTransport
to be able to mock blocking receivesreceive
method that uses a single method interface to delegate handling of sending messages to connectionManager. There are also some changes with MockWebSocketTransport that allows blocking incoming acks/nacks. This class is also now exposed so that we can read sent published messages directly. Please note that changes done here for these classes only serve the particular case of publishing. I think it can be improved to contain other protocol actions too.Some changes are inspired and taken from #842
Closes #474