2

I have a server application that can return a huge response (>10gb) via HTTP. The response is dynamically generated and sent in chunks to the client. The client (curl) could be slow in consuming the content generated by the server, this causes the server to stop and wait. The problem is that the server then never resumes.

I'm using EpollEventLoopGroup.

Here is what seems to happen:

  1. The server spits out data really fast (using writeAndFlush()).
  2. The client cannot keep up reading the data (I saw several posts about Netty and slow clients)
  3. The server stops sending data by setting setFlag(Native.EPOLLOUT);: https://github.com/netty/netty/blob/4.1/transport-classes-epoll/src/main/java/io/netty/channel/epoll/AbstractEpollStreamChannel.java#L447-L449
  4. The server stops sending data because calls to flush are actually unsuccessful, see this check: https://github.com/netty/netty/blob/4.1/transport-classes-epoll/src/main/java/io/netty/channel/epoll/AbstractEpollChannel.java#L551-L559 (note this checks for the same flag set above !isFlagSet(Native.EPOLLOUT))
  5. For some reason the server never goes back into a writing state (clearFlag(Native.EPOLLOUT)).
  6. Since no data is flushed to the client the ChannelOutboundBuffer keeps growing, as the server keeps producing data, until I get OOM (Netty Direct Buffer).
  7. If after the writeAndFlush() I check for channel.isWritable() and stop until the channel is writable again, it will wait forever, because the channel will never be writable again.

My question is, why does the server never goes back into writing to the client?

Simone Rondelli
  • 356
  • 1
  • 18
  • Does your handler override the [channelWritabilityChanged](https://netty.io/4.1/api/io/netty/channel/ChannelInboundHandler.html#channelWritabilityChanged-io.netty.channel.ChannelHandlerContext-)? The issue you describe should be solved by using it: https://stackoverflow.com/a/64983174/5162472 – dfogni Mar 13 '23 at 20:08

0 Answers0