Thanks Sergii, for the response. This clarifies my doubt. Best regards, Darshan
On Thursday, March 21, 2024 at 5:41:39 AM UTC+5:30 Sergii Tkachenko wrote: > Ok, I might've went a bit to much into the weeds of HTTP streams with my > answer. > > > 1. when the program calls streamClientSender1.onNext(request), request > will be sent in a stream, if I call it again will it be in the same stream > as long as the age of the stream is within max connection age ? > First, to clarify - the stream is not created whenever onNext is called. > It's created on the first stub.sendRequest call. The stream will persist > until the RPC is complete. > > > 2. does streamClientSender1.onNext() and streamClientSender2.onNext() > use different streams to send request, since they are two different > streamObserver objects. > Yes, two different streams - just with the same correction that > stub.sendRequest is what initiates a stream. > Messages is sent in order and tied to a stream. > > > 3. Is there a way to get StreamID of streams created and print it as a > verification step so that the above two questions can be answered ? > Not really, stream ids are kept internal. If it's just something you're > curious about, you can always use the debugger. But you shouldn't do > anything stream-id-related in the code, see > https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#stream-identification > : > > All GRPC calls need to specify an internal ID. We will use HTTP2 > stream-ids as call identifiers in this scheme. NOTE: These ids are > contextual to an open HTTP2 session and will not be unique within a given > process that is handling more than one HTTP2 session nor can they be used > as GUIDs. > > Sergii > > On Tuesday, March 19, 2024 at 11:07:38 PM UTC-7 Sergii Tkachenko wrote: > >> Hey Darshan, >> >> Right now I'm not entirely sure I'll be able to answer your question with >> absolute confidence. >> I'd like to say "yes, stream is created on first headers sent, and stream >> id not going to change until RPC dies", but there might be some nuances >> depending on the transport used, f.e. Netty's StreamBufferingEncoder. >> I'll speak with my TL to clarify this. >> I don't think there's a clear way to get the stream ID, except I've >> noticed it's tracked via PerfMark <https://github.com/perfmark/perfmark> >> when it's enabled: >> >> https://github.com/grpc/grpc-java/blob/68eb639b1cd38c161a3113bd50e731c04ac51fef/core/src/main/java/io/grpc/internal/ServerImpl.java#L464-L465 >> >> <https://github.com/grpc/grpc-java/blob/68eb639b1cd38c161a3113bd50e731c04ac51fef/core/src/main/java/io/grpc/internal/ServerImpl.java#L464-L465> >> >> I'll follow up on your questions, but could you please clarify: >> >> 1. Your code snippet: are you talking about the client side, or the >> server side? >> 2. Is there anything specific you're trying to achieve? >> >> Best Regards, >> Sergii >> >> On Monday, March 11, 2024 at 8:48:38 AM UTC-7 Darshan J Gowda wrote: >> >>> Hi everyone, >>> I'm trying to understand how many streams are getting created in one >>> grpc connection (Bidirectional streaming) whenever I call onNext() using a >>> StreamObserver object. Below is my code context >>> >>> StreamObserver<Response> responseStreamObserver1 = >>> getResponseObserver(); >>> StreamObserver<Response> responseStreamObserver2 = getResponseObserver(); >>> StreamObserver<Request> streamClientSender1 = >>> stub.sendRequest(responseStreamObserver1); >>> StreamObserver<Mbus> streamClientSender2 = >>> stub.sendRequest(responseStreamObserver2); >>> >>> My question is, >>> 1. when the program calls streamClientSender1.onNext(request), request >>> will be sent in a stream, if I call it again will it be in the same stream >>> as long as the age of the stream is within max connection age ? >>> 2. does streamClientSender1.onNext() and streamClientSender2.onNext() >>> use different streams to send request, since they are two different >>> streamObserver objects. >>> 3. Is there a way to get StreamID of streams created and print it as a >>> verification step so that the above two questions can be answered ? >>> >>> Thanks and regards, >>> Darshan >>> >> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/ddbb14dd-c44b-4920-8263-c9c75449f39en%40googlegroups.com.
