You should be looking to run the grpc server in the async mode. That'd make sure that there is not a thread per server streaming rpc (you control the threading model).
On Sunday, October 21, 2018 at 4:48:24 AM UTC-7, Michael Martin wrote: > > Hello, > I choose grpc to replace a REST data interface together with Server-Events > (SSE /Signalr /Websockets) with a single "non proprietary " protocol. > > I found a downside of grpc in terms of Server-Sent-Events: > There will always be a blocking thread. -> > https://github.com/grpc/grpc/issues/8718#issuecomment-354673344 > My own implementation: https://pastebin.com/HwPY6nLX > > So far i found no other way to implement (Server-Sent-Events), than to > have the requesting thread to block for eternity (or at least for event > subscription time) with a responseStream. > This results in an enormous amount of threads "hanging in sleep" ( number > of subscribed clients * number of server side events). > > In Terms of scaling this is a bottleneck i am trying to adress here. > Has any of you better implementations or ideas? > > In conclusion I wonder if there are any plans to make grpc a better > SSE/Signalr/Websockets alternative in terms of server side events, cause > in my humble opinion the only problem is that currently a responseStream > cannot survive the life-time-end of the initial request. > > Thanks for your time in advance > > Michael > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/97c36db8-d9b3-4718-bac4-943f680c4014%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
