Simplify implementation of back-pressure in StreamObserver-based stub

Pending API changes can allow reactive/async pattern for interacting with flow control and applying back pressure: https://github.com/grpc/grpc-java/pull/1545/files

In many cases, automatic back-pressure in generated stubs could be very useful – e.g. having calls to StreamObserve#onNext(T) block instead of queueing.

It’s been pointed out that this could cause deadlock for bidi-streaming operations, so perhaps we can just not expose this functionality for bidi-streaming calls?

It may also be worth pointing out that most other runtimes (wrapped languages and Go) already expose streams via blocking operations and already require that apps be aware of and work-around possible deadlock issues resulting therefrom. So maybe providing similar mechanisms in Java is fine, with said caveats.

Another possible alternative could possibly be done in an extension/add-on instead of in GRPC. For example, wrapping streaming requests and responses with RxJava Observables may further simplify the async case enough to make the synchronous (and possibly-deadlock-prone) case unnecessary.

[OlegDokuka]

@ulfjack. Please, consider using RSocket which supports backpressure correctly - http://rsocket.io/

Cheers.

[carl-mastrangelo]

@stephenh Yes, you app threads, as provided to executor() when you set up your Channel / Server. If you stall all your threads, none of them will be able to take more traffic. The pushback logic probably needs to live outside gRPC code, and not inline as in your example above. If you are calling the stubs from your own threads (not on the executor you gave to the channel) then you are probably fine blocking.

IE is actually a “collaborative” feature. You have to want an IE in the reciever, and also have to intentionally interrupt another thread (such as on Future.cancel(true)). The trouble comes from code you may not own interrupting your code. If you aren’t expecting an IE, its better to just let it propagate.

@cbornet There are two levels of FC: wire and API. The gRPC API is message based, which is converted to byte based in the library. I agree, this is not well covered anywhere. One effect that is not obvious is that unary calls generally don’t honor the message flow control, but do honor the byte flow control. That means it is still easy to overload your sender if you don’t pay attention to isReady, because they will buffer up in memory. One day I will write a comprehensive guide on how this works, but that’s extremely time consuming and thus hasn’t been a priority.