#grpc

Hey, we have a java set of applications using GRPC 1.0.3 (I know ancient) and we are having an issue where it looks like "Memory is being leaked", but it's not really. What is happening is a huge burst of requests come in and then GRPC creates a lot of executors to handle the burst of requests

Is there some way to limit how many executors GRPC will make via netty? not finding how to do it atm...or is this something that got changed later on and we should really try upgrading to a newer GRPC?

If we do have to upgrade (which we want to, but wanted to wait a bit longer till some other things were sorted out), do all systems using GRPC have to be upgraded at the same time? Or can we bump the GRPC version in each area one by one without nay backwards compatibility issues?

Hi all, does grpc for golang supports flow control in the rpc call level?

I mean something like this example from grpc-java https://github.com/grpc/grpc-java/tree/master/e...

MasterGberry: years ago I remember reading about a magic variable you could set that controlled the number of workers Netty would make, but this is long enough ago I may be imagining that

MasterGberry: If the problem is netty event loops, you can use io.netty.eventLoopThreads system property to control the number. You can also pass your own EventLoopGroup to NettyServerBuilder.workerEventLoopGroup and .bossEventLoopGroup.

But I'd actually expect the problem is with the default application executor which is a CachedThreadPool. You can override it with ServerBuilder.executor(Executor).