A debugging session using ClientCrashTest makes things clearer to understand.
This is the code path on the server when the client crash:
NettyAcceptor$MessagingServerChannelHandler.channelDisconnected() is triggered
-> RemotingServiceImpl.connectionDestroyed() is called
* the connection is removed from RemotingServiceImpl connections map
-> RemotingConnectionImpl.destroy() is called
-> RemotingConnectionImpl.internalClose() is called
-> NettyConnection.close() is called
-> NettyAcceptor$Listener.connectionDestroyed() is called
-> RemotingServiceImpl.connectionDestroyed() is called *again*
* the connection is no longer in the connections map, the code path
stops here
Nowhere in the code path, RemotingConnectionImpl's failureListeners are notfiied to
clean up server-side resources associated to the remoting connecion (e.g. ServerSession is
a FailureListener)
The callListeners() call in RemotingConnectionImpl.destroy() has been commented by Tim
(r5467) because it affects clustering.
However we still need to cleanup server resources when the remoting connection impl is
destroyed.
As an aside, BridgeImpl is also a FailureListener. If the other node crashes, the Bridge
won't be notified of the failure and won't have the opportunity to clean up its
resources too.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212273#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...