Native epoll transport should honor AUTO_READ flag

[wazhar]

Expected behavior

Data should only be read when requested, if AUTO_READ option is set to false

Actual behavior

When using Epoll transport, netty calls handler's channelRead0 without requesting read, even if AUTO_READ option is set to false. NIO Transport on the other hand works as expected.
This could be a problem if you are acting as a proxy.

Steps to reproduce

This is reproducible using small sized data I could reproduce it starting from 1 byte till 150k. Client must close connection as soon as done writing. Here are some settings I used.

1. SO_RCVBUF option was not set, although setting it didn't help.
2. AUTO_READ false
3. TCP_NODELAY false
4. SO_REUSEADDR true
5. cat /proc/sys/net/ipv4/tcp_rmem
   4096 87380 6291456
6. /proc/sys/net/ipv4/tcp_wmem
   4096 16384 4194304

This could help generating test data quickly:
cp some_large_file 10k_file
truncate -s 10240 10k_file
nc host port < 10k_file

Netty version

4.1.6.Final

JVM version

java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)

OS version

Linux 4.8.15-300.fc25.x86_64
x86_64 x86_64 x86_64 GNU/Linux

[blueswhisper]

may be you should use Epoll level trigger, default Epoll Mode is edge trigger, see this

[wazhar]

Setting LEVEL_TRIGGERED for bootstrap option EPOLL_MODE did not help.

[Scottmitch]

Client must close connection as soon as done writing.

IIRC if we get a EPOLLRDHUP then we must read until we get a socket error for stream sockets [1] while in ET mode as we may not be notified of activity on that FD again. This may not be necessary in LT mode, and especially if NIO transport is still able to deliver all data. I will need to investigate more.

[1] https://github.com/netty/netty/blob/4.1/transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollRecvByteAllocatorHandle.java#L57