Followup question: Java Manual Flow Control

[Nathaniel Jones]

Hello,

I'm following up on my questions here with another, more specific question on the manual flow control example code (any feedback on my recent questions appreciated as well).

My understanding of the example code is:

1. The client is sending the names to the server and respecting outbound flow control with this condition + using its ready handler.

2. The server disables auto flow control, which means that it won't process an onNext message (from the client) until it calls request(1).

3. The server's ready handler then ensures the outbound direction (to client) has capacity before it "primes the pump" by calling request(1) (and it later only ever calls request(1) when there's outbound capacity). This use of manual flow control is providing the invariant that "if the server processes an onNext, we know there is capacity to send the ACK message to the client [without excess buffering]." If the server didn't drop into manual flow control mode, and simply processed onNext automatically when a message came in, it runs the risk of its outbound onReady to be false, and then it's stuck with a message that it can't ACK back to client safely (e.g. case where client sends many messages to server quickly, but client can't receive them as quickly).

If that's all correct, my question is around the manual flow control in the client code - the client drops into manual mode here. Its onNext is very simple - print the message, and then call request(1). Is it fair to say that the client's usage of manual flow control is simply re-implementing "normal" behavior? The server code is doing what it needs to do to make sure it's responding to the client 1 message at a time, so wouldn't the overall example be the same if the client didn't use manual flow control, and simply logged out the server message in its onNext?

Thanks again!

[Larry Safran]

You are correct that this is basically doing the "normal" thing.  However, with the manual flow control you are explicitly controlling when it starts looking for messages rather than having that process trigger when a new message arrives.  This could be useful if you had time consuming initializations or were waiting for some event to happen before accepting messages.