IdleStateAwareChannelHandler.channelDisconnected(...) is not called intermittently

["이희승 (Trustin Lee)"]

Sorry for a late reply.  The behavior you observed doesn't sound right.
 Let me look into this issue.  Thanks for reporting it and thanks again
for your patience!

Regards,
Trustin

Daniel Ferber wrote:
> After more investigation, I have a supposition that there is a race condition
> in NioWorker.close() when the channel is requested to close by a thread that
> is not a worker thread.
> 
> The HashedWheelTimer thread runs the idle event that calls
> Channels.disconnect() and that indirectly calls NioWorker.close(), causing
> the socket to be closed. Immediately, the worker thread awakens (because it
> detected that the socket is now closed) and also calls NioWorker.close().
> 
> The race condition might cause incorrect execution if:
> One thread reads "connected = channel.isConnected();" to be true, closes the
> socket and calls "channel.setClosed()". The setClosed() changes the internal
> status to "closed" but does not yet enter the synchronized block to update
> the channelFuture. Under unfortunate conditions, the JVM schedules the
> second threads just at this moment.
> 
> The second thread reads "connected = channel.isConnected();" to be FALSE(!),
> since it was recently updated to "closed" by the first thread. The second
> threads closes the socket again (with no effect), enters setClosed(), enters
> the synchronized code that updates the ChannelFuture and gets permission to
> enter the block that dispatches the events. However, the second thread
> falsely believes that the socket was not connected nor bound, and skips the
> channelDisconnected and channelUnbound events.
> 
> The first threads is scheduled again, since the channelFuture was already
> updated, it does not gain access to the events block and returns.
> 
> Perhaps the complete Channel.setClosed() should be synchronized to prevent
> both Threads from updating the channel status at the same time, and to
> prevent from one thread read an inconsistent result.
> 
> Or even better, as already suggested in the jira, have all events, including
> timer events, be executed by only one thread.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 290 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20101123/8119429a/attachment-0001.bin