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
Requests may have non-sequential stream ids #749
Comments
Can you please point to a certain spec section that says anything on that?
I can not see any possible solution without involving complex synchronization in order to ensure the streams ID are identical to the order in which payloads come into the network. Even though the id is generated at the same time the payload, there is always racing on delivering a frame. Also, it makes sense for HTTP/2 (https://tools.ietf.org/html/rfc7540#section-5.1.1) which is based on TCP connection but now imagine Aeron or QUIC connection I guess the reference to HTTP/2 is more on the fashion how ids are generated rather than on that particular restriction related to the fact that HTTP/2 is TCP based What do you think on that @nebhale @smaldini @rstoyanchev @rdegnan @linux-china @stevegury @yschimke? |
I read that as they should be sequential
Transports are required to send all frames in order. Given above, if there are 2 client requests, there
One solution from top of my head - existing (and future ones, like quic) transport implementations are netty based so there is |
@mostroverkhov the implementation does not contradict anything said in the spec. StreamIdSupplier issues ids sequentially.
yeah, that works out
Due to HTTP/3 spec, messages within a logical stream are delivered in order but there are no guarantees of delivering messages in total order see (https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-6). It means that issuing stream id 1, flushing it to the network, issuing stream id 3 flushing it to the network may end up delivering stream id 3 earlier than stream id 1, which is not a big deal. I guess the most important is that packets within a logical stream are delivered with the order of packets issuing. Maybe we have to clarify spec with regards to upcoming network protocols. What do you think @nebhale @linux-china @smaldini @rdegnan @yschimke @tmontgomery @rstoyanchev @spencergibb |
This looks like a good start - can you explain why introduce separate scheduler instead of delegating to transport which likely has event loop already @OlegDokuka @rstoyanchev ? |
@mostroverkhov Having a scheduler in on the requester side is a temporary fix as the result of improper architecture.
Thus, the simples and the most straight forward solution for achieving serial ID issuing to satisfy possible implementation of HTTP/2 based transport was using a separate ThredPool (e.g Schedulers.single(Schedulers.parallel())) |
The thing is request frames end up on transport event loop anyways, you just add redundant scheduler queue without possibility to opt out - not everyone needs parallel scheduler, but many would benefit if transport scheduler was exposed on RSocket interface so clients can use them in respective operators without hopping threads |
As I mentioned before, the need to use eventLoop is specifically to support Http/2 case. It Introducing a new API that does not pay the bill for future support, especially taking into account that this code will be eliminated and redesigned. Thus, RSocketRequester will be unaware of Therefore, having that minimal theoretical overhead is not a big deal |
Happens when request (for all interactions) subscriptions race
rsocket-java/rsocket-core/src/main/java/io/rsocket/RSocketRequester.java
Line 218 in c66dfb8
rsocket-java/rsocket-core/src/main/java/io/rsocket/RSocketRequester.java
Line 209 in c66dfb8
The text was updated successfully, but these errors were encountered: