Skip to content

Conversation

@OlegDokuka
Copy link
Member

This PR is a follow up to #811 and therefore introduces a non-thread safe way to issue stream id since this class is never called in the concurrent fashion

@OlegDokuka OlegDokuka added this to the 1.0 milestone May 2, 2020
@OlegDokuka OlegDokuka requested a review from rstoyanchev May 2, 2020 12:34
this.streamIdSupplier =
isResumeEnabled
? new ResumableStreamIdSupplier(streamIdSupplier, receivers)
: streamIdSupplier;
Copy link
Contributor

@rstoyanchev rstoyanchev May 4, 2020

Choose a reason for hiding this comment

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

Is checking the receivers map related to resume at all? As long as the same StreamIdSupplier is used, numbers are always going up and shouldn't be repeated.

Looking at the history, the check was introduced in e9f2efe as part of a fix for overflowing so maybe that should always be present?

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess this should not be the case since if we going to come to http2 transport, then once we get it overflowed - everything will be broken.

Spec also mentions that reuse of stream-id is recommended only with resumability -> https://github.com/rsocket/rsocket/blob/master/Protocol.md#lifetime.

@linux-china, @jjeffcaii do you know folks, whether it should be re-usable id all the time, I remember you were asking about that, but I'm not sure that it is always needed.

@rstoyanchev Maybe we can do a configuration?

Copy link
Member Author

@OlegDokuka OlegDokuka May 4, 2020

Choose a reason for hiding this comment

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

Alright, I guess in this PR I will just provide a relaxed stream id generation, thus going to rollback most of the changes. No need to care about all the things right now

Copy link
Member

Choose a reason for hiding this comment

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

@OlegDokuka Yes, SteamID is re-usable by default in current Go and Rust SDK.


import io.netty.util.collection.IntObjectMap;
import java.util.concurrent.atomic.AtomicLongFieldUpdater;
interface StreamIdSupplier {
Copy link
Contributor

Choose a reason for hiding this comment

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

This should have some Javadoc at least, as a reminder, that explains the class is not thread-safe and assumes the issuing of id's will not be done concurrently (e.g. serial sending of requests).

@OlegDokuka OlegDokuka force-pushed the bugfix/streamId-order branch from 6a74390 to 7461326 Compare May 4, 2020 08:46
@OlegDokuka OlegDokuka marked this pull request as draft May 4, 2020 08:50
@OlegDokuka OlegDokuka force-pushed the bugfix/streamId-order branch 2 times, most recently from dcd413b to de75f44 Compare May 4, 2020 09:44
@OlegDokuka OlegDokuka modified the milestones: 1.0, 1.0.1 May 12, 2020
@OlegDokuka OlegDokuka removed this from the 1.0.1 milestone Jun 4, 2020
@OlegDokuka OlegDokuka closed this Aug 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants