ReactiveExecutor overrides NettyServerBuilder.executor? about reactive-grpc HOT 3 CLOSED

Hi @bartlomiej-dawidow,
I haven't been ignoring your question. It really got me thinking and ultimately drove some changes to RxGrpc.

The .observeOn() calls you pointed out were originally added from a lot of experimentation while developing early versions of RxGrpc. Your question inspired me to dig deeper.

The way I'm using .observeOn() takes advantage of its internal buffer. A typical user calls .subscribe(x -> handleX(x)). Under the hood, this translates to a request(Long.MAX_VALUE) request. I don't want to send request(Long.MAX_VALUE) back through the gRPC service. For comparison, gRPC's automatic flow control calls request(1) each time a new message is requested. The .observeOn() internal 128 message buffer helps bridge the flow control. When a downstream subscriber calls request(Long.MAX_VALUE), .observeOn() translates that to many upstream request(128) calls, which gRPC can handle.

After some further experimentation, I found a way to get the functionality out of .observeOn() without needing to spin up a new thread pool.

from reactive-grpc.

Hi @rmichela, first of all thanks for your explanation and the fix.
I just verified that version de7552b does not spawn the extraneous threads.

There are still two grpc-default-executor threads but I'm guessing they are started by DnsNameResolver.

from reactive-grpc.

That sounds right. I'll be cutting a release in the next day or so.

from reactive-grpc.