reworks InMemoryResumableFramesStore and improves its tests coverage #1014
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Main Changes Description
At the moment Resumability implementation is unstable due to its non-well-covered reworked impl.
As it was uncovered, the main root-cause of the problem is the incorrect state synchronization in InMemoryResumableFrameStore when it comes to the connection reestablishment (e.g. the previous connection was lost so we need to go through the resume handshake phase).
As it was observed, the local producers may produce more elements while the new subscriber iterating over the cached value may miss some updates.
To resolve the mentioned problem, InmemoryResumableFrameStore is reworked again with the thought of backpressure (via ASYNC fusion) and fully sequentially signals processing (using WorkInProgress pattern).
The first improvements allow draining elements from the upfront
Publisher
(at the moment UnboundedProcessor which does not support backpressure but we should have a proper once #752 is implemented) only when there is an active connection. In general, relying onqueue.poll
only (instead of handling data fromonNext
) decreases the amount of potentially concurrent signals we have to deal with and ensures that the new connection does not have to mess with duplicates-checking logic.The second improvement eliminates the need for
synchronized
keyword and replaces it withvolatile long state
machine over which we can expose various changes without introducing an expensive MpScQueueSide Changes Description
There are some LocalDuplexConnection and UnboundedProcessor modifications as a part of this PR. These modifications are mainly to ensure that e2e resumability tests pass with LocalTransport.
LocalDuplexConnection
(used in LocalClient/ServerTransport) embraces UnboundedProcessor to exchange frames between peers. Before these changes, it was not possible to track when all the frames are delivered / discarded. Thus, it was not possible to notify about the real termination of the DuplexConnection. The modifications to UnboundedProcessor provide aondisposehook
handle which allows tracking when the queue is cleaned and closed - hence notify the duplex connection that it can be terminated as well.