Retry Issue with Gateway as RSocket Proxy

[FWinkler79]

I just saw issue #1319, so I apologize if this is simply not yet implemented.

I saw @spencergibb's nice presentation on SCG and RSocket and took the liberty to fork his sample and adjust it a little for my tests.

I added two failure-scenarios to the sample, one of which I would have expected another outcome of. I modified PingService's request-channel handling to retry in case of errors.

The scenario is as follows:

1. run two gateway instances in cluster mode
2. run ping and see maximum back pressure applied from gateway
3. run pong and see how pings and pongs start flowing
4. stop pong, simulating the pong instance going down.
5. start pong again.

What I was hoping to see, is that ping receives an error, retries and again is confronted with maximum back pressure from the gateway.

What I saw instead is, that ping retries, silently keeps sending pings to the gateway cluster which seems to buffer the pings, and then forwards all of them to pong once that is up again.

I am not sure this is intended, and I am not 100% sure if maybe I have a bug in my own coding, but I think, it would be better, if the gateway sent maximum back pressure also in the case a remote service goes down. Maybe that goes into the direction of Deregistrations on disconnect in #1319?

If you want to try this out yourself, here is my adjusted fork:
https://github.com/FWinkler79/spring-cloud-gateway-rsocket-sample#failure-resiliency-2

It would be great to have this feature, as it would make it so much easier for application developers to create resilient Cloud applications - simply by properly handling back pressure (which they generally should have to anyway).

Also, having the gateway buffer the incoming requests from clients and replay them to servers once they are up again, might cause the servers to immediately go down again.

If my understanding is incorrect, please let me know.

[spencergibb]

Closing in favor of spring-attic/spring-cloud-rsocket#7