TCP_USER_TIMEOUT property setting issue

[hlx502]

The channelFactory may create a NioSocketChannel, but here it uses Utils.maybeGetTcpUserTimeoutOption() to determine whether to set the TCP_USER_TIMEOUT. It may lead to setting TCP_USER_TIMEOUT when using NioSocketChannel, but in fact, only EpollSocketChannel supports setting this property. I feel that the judgment here is not strict enough. Should we consider optimization?

[ejona86]

I'd expect NioSocketChannel to ignore the unknown (to it) option. Have you seen any error caused by this?

[hlx502]

During the testing of ETCD, nio was used. But it seems that the call stack has set TCP_USER_TIMEOUT. There are no errors, only the warn log below will be generated. Can we add a determination of the current channel type in NettyClientTransport to avoid setting TCP_USER_TIMEOUT
log:

stack:

[ejona86]

Ah, okay. It would be good to avoid the warning. Although we don't know the type returned by the channelFactory, so it may be a bit hard to figure out which case we are in. Do you have any ideas on how to fix it? We could choose to avoid TCP_USER_TIMEOUT if someone sets the channelFactory on NettyChannelBuilder.

[hlx502]

It seems that modifying NettyChannelBuilder is not a good solution. Maybe we can set the TCP_USER_TIMEOUT attribute after the channel is registered and before the channel is connected. If it's feasible, I'll file a PR to fix it.

[ejona86]

I honestly don't know if that works. We could do it before connect(), which is good. But there's two risks:

1. it isn't running on the event loop
2. the channel might not notice the change in option

Looking at the code, it seems Netty directly modifies the socket when called and socket is final. https://github.com/netty/netty/blob/7679b9efdec71b54d06db91eef40ad913681294a/transport-classes-epoll/src/main/java/io/netty/channel/epoll/EpollSocketChannelConfig.java#L161

Yeah, seems it could work.