Netty - calling channel.disconnect() actually closes the channel

Question

I am using Netty version 2.6.0.Final.

If I'm understanding the Netty documentation correctly, calling disconnect() on Channel should allow me to call connect() to connect again later. However, when I call disconnect(), both channelDisconnected() and channelClosed() of my SimpleChannelHandler subclass get called.

I opened this in debug mode and basically the order of events is:

1. I call disconnect() on my Channel

2. Channels.disconnect() gets called:

   public static ChannelFuture disconnect(Channel channel) {
     ChannelFuture future = future(channel);
     channel.getPipeline().sendDownstream(new DownstreamChannelStateEvent(
           channel, future, ChannelState.CONNECTED, null));
     return future;
   }
   

3. Eventually, NioSocketPipelineSink.eventSunk() gets called, and the related part is:

       case CONNECTED:
           if (value != null) {
               connect(channel, future, (SocketAddress) value);
           } else {
               channel.worker.close(channel, future);
           }
           break;
   

So since value is null and the state is CONNECTED, the channel gets closed (although according to here CONNECTED with null should indicate a request to disconnect, not necessarily close.

So am I missing something here? What's the point of disconnect() if it just results in the channel being closed?

This isn't a huge problem, because if I need to I can just create a new Channel for my situation, but from initial inspection this seems like a Netty bug, unless I'm just misunderstanding how this is supposed to work or I'm doing something silly.

Answer 1

One intention of Netty is to present a unified Channel abstraction that works more or less the same for connection oriented sockets (TCP) as for connection less sockets (UDP), regardless of the underlying implementation, OIO, NIO or AIO. Since there are quite a few differences, the unified interface will look a bit strange for some pieces of a particular implementation.

The act of disconnecting a TCP socket implies closing it (at least from the Java API perspective). But disconnecting a UDP socket does not imply closing it, just removing the association between the local ip address/port and the remote ip address/port.

So, no, you are not doing anything silly, but I would recommend acting upon OPEN/CLOSE events instead, unless you have a real need for "connecting" a UDP socket to different remote targets during its life time.

EDIT: missed an important "not" in the preceeding paragraph.