URGENT: Sending async response over grpc

[Abhijeet Tiwari]

So I was wondering about this usecase:

1) let's say a java based client that has opened a server streaming rpc
2) after this, we are to receive some info through a webhook on our server, but it might take some time

3) we have to send this info received over webhook to the java based client over the server streaming rpc

4) my question is, is there a way i can store the info of that stream and then invoke stream.Send() when i receive the info over webhook

5) also, there might be 3 different servers(with a load balancer), so the rpc could be opened over 1st, but the webhook hit would have occured on 3rd, so even if i store this stream object on a global, let's say redis cache, will I be able to establish a connection to the client from the 3rd server?

[Eric Anderson]

On Wed, Mar 13, 2024 at 1:11 PM Abhijeet Tiwari <abhije...@gmail.com> wrote:

1) let's say a java based client that has opened a server streaming rpc
2) after this, we are to receive some info through a webhook on our server, but it might take some time

3) we have to send this info received over webhook to the java based client over the server streaming rpc

You keep mentioning the Java client. What language is your server?

4) my question is, is there a way i can store the info of that stream and then invoke stream.Send() when i receive the info over webhook

5) also, there might be 3 different servers(with a load balancer), so the rpc could be opened over 1st, but the webhook hit would have occured on 3rd, so even if i store this stream object on a global, let's say redis cache, will I be able to establish a connection to the client from the 3rd server?

The stream is not a data object. It can't be serialized and stored in a DB. It is only useful on the server that has the object. You can't establish a new connection to the client; you can only use the existing one.

Instead of storing the stream in Redis, you could generate a unique key and store the stream in a map on the server that received the stream. Then store (server id, stream key) in Redis. When the webhook fires, forward the information to the appropriate server and have that server send back to the client.

[Eric Anderson]

+grpc-io, so Go folks can answer

On Tue, Mar 19, 2024 at 9:05 PM Abhijeet Tiwari <abhije...@gmail.com> wrote:

Hey, thanks a lot for the response!

My server is actually written in golang.

I also wanted to know that I'll have to use a combination of for loop with some time.Sleep() maybe to keep the server streaming rpc alive. I can't return the rpc function in case I want to use this connection later. Am I correct?

So let's say there are multiple connections tomorrow at the same point of time, which means this for loop and time.Sleep() will keep holding up goroutines until we send the response through rpc and return. Will that affect the server performance or go routines are light and this will be handled easily. 

My whole concern is around is there any method to keep a server streaming rpc alive without using a for loop? Or that has to be there to keep the connection alive.

[Zach Reyes]

Hello Abhijeet,

There can be a long lived stream that stays alive without the use of a for. The for (while true essentially) is a convinent way to structure receiving messages/sending messages. You don't need a for loop/time.Sleep to keep the stream alive. gRPC-Go server's do fork a goroutine for each Conn and then each Stream on that connection, however that shouldn't affect performance except the minisucle amount of memory used in that goroutine. The context switcher will see the goroutine is blocked, and performance won't be hit too hard.

Zach Reyes