[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messages are lost on Queue?
jmesnil
do-not-reply at jboss.com
Tue Feb 24 12:41:18 EST 2009
ok, let recap what the problem is.
We want to ensure that server resources are properly cleaned up on the server no matter how the client is closed (properly, crash, network failures).
1/ normal case:
- the client closes the session
- the client exits.
=> the server resources are properly cleaned up when the CLOSE packet is handled by the server session.
* there is no resource cleanup when the connection is closed (as triggered by Netty channelDisconnected event)
2/ unclean case (doing a Ctrl+C, a kill-9 or a System.exit leads to the same event on the server side):
- the client exits without closing the session
=> the server will be informed by a channelDisconnected() event (for Netty)
* we wait for the connection TTL before cleaning up the server resources associated to the connection
3/ socket exception
- a problem occurs on the network
=> the server will be informed by a Netty exceptionCaught event.
* we know for sure the connection is not working, the resources are cleaned up immediately
4/ missing heartbeat (e.g the network is unresponsive)
- the client does not reply a pong to a ping from the server
=> in that case, we wait for the connection TTL (starting when the pong was missed) and clean up resources after the connection TTL is hit
cases #1, #3 & #4 works as expected (TODO: list the corresponding test cases)
case #2 is not working as expected:
- From RemotingServiceImpl point of view, both case #1 and #2 result in a connectionDestroyed event. We need to know more about it to decide if:
1. we destroy the connection immediately (clean case)
2. we keep it until the connection TTL is hit (crash case)
Trustin once talked about the SMTP protocol iirc which sends a "last" request before closing a connection.
We could do the same: just before closing the connection, we send a LAST request, so that we can know when the channelDisconnected event is triggered if the connection was closed properly (we received the LAST request) or not.
We can then pass the information to the RemotingServiceImpl which can then distinguish between case #1 and #2.
Sending this LAST request would occur in Channel.close().
We would intercept this LAST request in MessagingServerPacketHandler and flag its RemotingConnection as closed.
what do you think?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212689#4212689
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4212689
More information about the jboss-dev-forums
mailing list