Using version 1.7.21, a NettyResponseFuture never gets completed because the provider uses a channel that has already been closed and handled by closeChannel(...).

If I have read the source properly, what we have here is a classical race condition:

1. [in client thread] doConnect(...) is called and a cached channel is selected.

   At this point, the attachment connected to the channel is still DiscardEvent

   NettyAsyncHttpProvider.java#L913

   doConnect(...) checks that the connection isOpen(), which it still is.

   NettyAsyncHttpProvider.java#L923

2. [in I/O thread] The channel is closed by the remote end and channelClosed(...) is called. Since the attachment is DiscardEvent, nothing is done.

   NettyAsyncHttpProvider.java#L1341

3. [in client thread] doConnect(...) continues using the now closed channel by attaching a NettyResponseFuture to the channel.

   NettyAsyncHttpProvider.java#L937

4. [in client thread] doConnect(...) calls writeRequest(...) which checks if the channel is closed, which it is.

   NettyAsyncHttpProvider.java#L447

   However, writeRequest(...) does nothing about the fact, relying on channelClosed(...) to handle the situation. But, as channelClosed(...) has already been executed at step 2, the abort(...) or done(...) methods will never get called, resulting in that the listeners of the future will never get notified.