Regression: no cancel signal to the Publisher of a streaming response

[rstoyanchev]

The following change be41032#diff-bce0b5fb284a12e86df4fc9b4dc0908aR370 in 0.7.3 introduced a regression for an issue originally reported in SPR-15306 and fixed with 96daef2 in 0.6.2, affecting the ability to detect cancellation on a streaming response when the client goes away.

To preserve the original fix, ideally autoRead should remain enabled until the end of output for the current response. Another idea might be to target streaming scenarios, e.g. use of sendGroups is a good indication, although that seems a bit too indirect and potentially an incomplete solution.

Or perhaps a different approach should be considered altogether. Consider the same issue exists on the clients side. If a client streams up to a server, and the server goes away, the client publisher does not get a cancellation. I will create a separate ticket for that.

[rstoyanchev]

Correction:

If a client streams up to a server, and the server goes away, the client publisher does not get a cancellation.

Using the latest, I see the following if the server shuts down:

12:00:43.896 [reactor-http-nio-1] DEBUG org.springframework.web.reactive.function.client - onError(io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: localhost/127.0.0.1:8081)
12:00:43.897 [reactor-http-nio-1] DEBUG org.springframework.web.reactive.function.client - 
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: localhost/127.0.0.1:8081
	at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
	at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
	at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:325)
	at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:340)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:633)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.ConnectException: Connection refused
	... 10 common frames omitted

So in the latest, the client seems to realize right away the connection is closed. Nevertheless since the scenario is similar and symmetrical (client streaming up vs server streaming down) it may be worth considering the approach for both at the same time.

This is based on demo-reactive-spring by the way, if you need a place to experiment with client to server streaming: 1) start LocationServiceApp, 2) run ClientUploadApp, 3) shut down LocationServiceApp.

[rstoyanchev]

Some more findings. On the server side, the response Publisher receives a cancellation as long as it keeps writing frequently, but if it stops writing, it remains unaware. On the client side, the same is true for the request Publisher, although the response will also produce the error shown in my last comment as long as the the request keeps writing. In other words the issue does affect both client and server side, so I've created #284 separately.

[smaldini]

So we need to investigate with Netty community how to do this efficiently. In short, introducing the autoRead trick which was used in previous version has the dangerous side effect of opening the valve for any traffic for a short window of time. At the same time, SSE and streaming scenarios should be encouraged to ping regularly their remote, something that is opinionated and cannot be done generically. For example, protocols such as WebSocket and RSocket or STOMP do present an heartbeat to their remote.