Fixes behavior of RequestChannel #736
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Did you miss a file? or is this a draft? |
|
@yschimke pushed fix |
OlegDokuka
force-pushed
the
bugfix/request_channel
branch
4 times, most recently
from
e24f3c2
to
ff009c8
Compare
simonbasle
reviewed
Feb 3, 2020
rsocket-core/src/main/java/io/rsocket/internal/FluxSwitchOnFirst.java
Outdated
Show resolved
Hide resolved
Closed
|
suppressed by #761 |
OlegDokuka
force-pushed
the
bugfix/request_channel
branch
2 times, most recently
from
d321e68
to
c853a39
Compare
OlegDokuka
force-pushed
the
bugfix/request_channel
branch
4 times, most recently
from
5339a88
to
268e1ae
Compare
Signed-off-by: Oleh Dokuka <shadowgun@i.ua>
Signed-off-by: Oleh Dokuka <shadowgun@i.ua>
Signed-off-by: Oleh Dokuka <shadowgun@i.ua>
OlegDokuka
force-pushed
the
bugfix/request_channel
branch
from
268e1ae
to
ab0ce37
Compare
OlegDokuka
commented
Apr 9, 2020
OlegDokuka
commented
Apr 9, 2020
Signed-off-by: Oleh Dokuka <shadowgun@i.ua>
OlegDokuka
commented
Apr 9, 2020
| .expectNextCount(3) | ||
| .expectComplete() | ||
| .verify(getTimeout()); | ||
|
|
||
| Assertions.assertThat(requested.get()) | ||
| .isEqualTo(257L); // 257 because of eager behavior of limitRate |
There was a problem hiding this comment.
@rstoyanchev for your attention. Here is the result of eager prefetch 1L (from the switchOnFirst + 256 extra from limitRate)
There was a problem hiding this comment.
oh... found a bug because of skip does extra request 1 but it should not
There was a problem hiding this comment.
fixed. prefetch should be exactly 256
Signed-off-by: Oleh Dokuka <shadowgun@i.ua>
OlegDokuka
force-pushed
the
bugfix/request_channel
branch
from
9ca64fe
to
fb97f43
Compare
OlegDokuka
commented
Apr 9, 2020
rstoyanchev
approved these changes
Apr 9, 2020
| // need to skip first since we have already sent it | ||
| first = false; | ||
| return; | ||
| } |
There was a problem hiding this comment.
The if (first) check could be replaced with inboundFlux.skip(1)?
There was a problem hiding this comment.
It was with skip initially, but, I figured out that skip does extra request(1) when it skips, so we have extra 1 element requested (I mentioned that in the comments that expected prefetch is 256, but it was 257)
The strategy is the following
- we do at the very beginning
request(1)(from theswitchOnFirst) to obtain the first element and then do the transformation. - Then, we send that obtained element as a part of
RequestChannelframe so it appears on the moment of delivery - Then, in order to not break backpressure because of the eager first element prefetch, we reduce 1 from the first upcoming request to the
switchOnFirst. - However, the first prefetched element is sent to the flux along the way, and that would be OK if we have just normal routing case, but, in case of RSocket, the first payload has already been sent so if we are not going to
skipthe first element, it will be delivered twice - Here comes the issue, if we use
skipthenskipoperator think that we need to fulfill the demand by requesting extra one element, but in fact we just need not skip butDROPelement instead without doingrequest(1)
simonbasle
approved these changes
Apr 9, 2020
rstoyanchev
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR provides a fix for the incorrect behavior of RequestChannel.
At this moment there is a couple of issues with that:
1.1) There was an incorrect expectation of signal ordering which is
requestNfrom the local downstream, onNext from the local upstream. In fact, signal order can be totally different and while we wait for first onNext signal, nothing prevents to perform a few morerequestNwhich is going to break correctness (see https://github.com/rsocket/rsocket-java/pull/736/files#diff-a87c12662c200847a65e4b44b57e2278R236)1.2) There was an incorrect behavior in case upstream terminates earlier than the remote responder so the downstream observed onComplete before it should do so. The RSocket-Spec says that the stream can be half-closed until both sides send the complete signal. (https://github.com/rsocket/rsocket-java/pull/736/files#diff-b0fea90eb4e3536e65de608e97f637f9L369)
I found that there could be racing between sending first frame and cancelation, so I added an additional flag that ensures that we released the given frame and no leaks going to appear. (see https://github.com/rsocket/rsocket-java/pull/736/files#diff-b0fea90eb4e3536e65de608e97f637f9R394)
In order to implement correct behavior of request channel I reimplemented the switchOnFirst operator to follow the behavior defined by RSocket-Spec (https://github.com/rsocket/rsocket-java/pull/736/files#diff-ec51e7f167b7b31f5b3c4b25f5233e8dR1)
This PR is a temporary fix on the upcoming rewriting of every stream to state-machine it is done in the RSocket-CPP https://github.com/rsocket/rsocket-cpp/tree/master/rsocket/statemachine
Signed-off-by: Oleh Dokuka shadowgun@i.ua