Closed TCP Channel (Netty 3.1.1GA)

["이희승 (Trustin Lee)"]

Thomas,

Thanks a lot for investigating this issue.  I checked in the fix and
will release 3.1.2.GA today to address this critical issue.

Trustin

On 08/23/2009 05:02 PM, Thomas Bocek wrote:
> Hi Trustin,
> 
> I investigated a bit more in this issue and found in
> NioClientSocketPipelineSink.java, in line 356 the method
> processConnectTimeout() that is called every ~500ms to check if a
> connection has timed out. In this method, the selector's key set are
> iterated and once a while there is a SelectionKey that is invalid and
> the channel is closed:
> 
> Line 359, NioClientSocketPipelineSink.java
> private void processConnectTimeout(Set<SelectionKey> keys, long
> currentTimeNanos) {
>   ConnectException cause = null;
>   for (SelectionKey k: keys) {
>    if (!k.isValid()) {
>     close(k);
>     continue;
>    }
> ...
> 
> However, the selectionKey is invalid because it has been successfully 
> finished in connect() in Line 384. So the connection is established and 
> the selectionKey is canceld. The SelectionKey remains in the set because 
> from the Java API it says: "Keys may be cancelled and
> channels may be closed at any time. Hence the presence of a key in one
> or more of a selector's key sets does not imply that the key is valid or
> that its channel is open." The result is that the connection is closed 
> (ClosedChannelException) even though it was successful. I think the 
> correct behavior of this method should be:
> 
> private void processConnectTimeout(Set<SelectionKey> keys, long
> currentTimeNanos) {
>   ConnectException cause = null;
>    if (k.isValid()) {
>     NioClientSocketChannel ch = (NioClientSocketChannel) k.attachment();
>     ...
> 
> The check for timeout should only be for valid SelectionKeys as invalid 
> keys are canceled or closed anyway. Second, the isConnectable is already 
> handled by processSelectedKeys(), so I think there is no need for that.
> 
> Thomas
> 
> Thomas Bocek wrote:
>> Hi,
>>
>> I'm having the following issue that once a while I get an exception due
>> to a ClosedChannelException. I made a test and this happens once per
>> every 10'000 connections or so and its very undeterministic. In the test
>> I open locally a connection, send data, wait for a reply, and close it.
>> Most of the time opening connection works, but in rare occasions it does
>> not.
>>
>> The exception gets set in:
>>
>> NioWorker, 731:
>>
>> if (localAddress == null || remoteAddress == null) {
>>   if (future != null) {
>>     future.setFailure(new ClosedChannelException());
>>   }
>>   close(channel, succeededFuture(channel));
>>   return;
>> }
>>
>> Here, localAddress is null, and remoteAddress is null. Before the future
>> is set, as far as I can see, NioClientSocketPipelineSink in line 146
>> calls register(...):
>>
>> if (channel.socket.connect(remoteAddress)) {
>>   channel.worker.register(channel, future);
>> } else {
>>   future.addListener(ChannelFutureListener.CLOSE_ON_FAILURE);
>>   channel.connectFuture = future;
>>   boss.register(channel);
>> }
>>
>> The socket in the NioClientSocketChannel class says: bound=false,
>> closed=false, connected=false, created=false, and the selector is open
>> so I expect that boss.register(...) is called.
>>
>> Here is the stacktrace:
>>
>> Thread [New I/O client worker #1-2] (Suspended (breakpoint at line 299
>> in DefaultChannelFuture))	
>> 	DefaultChannelFuture.setFailure(Throwable) line: 299	
>> 	NioWorker$RegisterTask.run() line: 731	
>> 	NioWorker.processRegisterTaskQueue() line: 260	
>> 	NioWorker.run() line: 199	
>> 	ThreadRenamingRunnable.run() line: 113	
>> 	IoWorkerRunnable.run() line: 53	
>> 	ThreadPoolExecutor$Worker.runTask(Runnable) line: 886	
>> 	ThreadPoolExecutor$Worker.run() line: 908	
>> 	Thread.run() line: 619
>>
>> How and when is it safe to assume that a channel is connected and has a
>> local and remote address set?
>>
>> I'm not sure if there is a mistake in my code (more likely) or in Netty.
>>
>>
>> Thomas
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users


-- 
- Trustin Lee, http://gleamynode.net/