@FWinkler79 said in spring-cloud/spring-cloud-gateway#1355 :
I just saw issue #6, 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:
- run two
gateway instances in cluster mode
- run
ping and see maximum back pressure applied from gateway
- run
pong and see how pings and pongs start flowing
- stop
pong, simulating the pong instance going down.
- 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.
@FWinkler79 said in spring-cloud/spring-cloud-gateway#1355 :
I just saw issue #6, 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:
gatewayinstances in cluster modepingand see maximum back pressure applied fromgatewaypongand see how pings and pongs start flowingpong, simulating the pong instance going down.pongagain.What I was hoping to see, is that
pingreceives an error, retries and again is confronted with maximum back pressure from the gateway.What I saw instead is, that
pingretries, silently keeps sending pings to the gateway cluster which seems to buffer the pings, and then forwards all of them topongonce 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.