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/bb2ab4df-5edf-4873-928a-f83dd9fae6cfn%40googlegroups.com.
