[ https://jira.jboss.org/jira/browse/JBMESSAGING-1421?page=com.atlassian.ji... ] Clebert Suconic updated JBMESSAGING-1421: ----------------------------------------- Summary: QueueImpl::consumer is not cleared when the socket is closed (was: Investigate Possible Message Loss When a Client is restarted) Description: When the client socket is closed, RemotingServiceImpl::connectionDestroyed is called but nothing is activing the FailureListeners on Server Side, as a result when a client created a consumer, the consumer will stay forever on QueueImpl. Look at the forum thread for more details. Assignee: Tim Fox (was: Clebert Suconic) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1421?page=com.atlassian.ji... ] Jeff Mesnil reassigned JBMESSAGING-1421: ---------------------------------------- Assignee: Jeff Mesnil (was: Tim Fox) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1421?page=com.atlassian.ji... ] Jeff Mesnil reopened JBMESSAGING-1421: -------------------------------------- the QUIT commit was reverted: the fix was not correct, it was possible that the QUIT message was sent from the client but never receives by the server before the connection was destroyed. We need to rethink the solution for this -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1421?page=com.atlassian.ji... ] Jeff Mesnil commented on JBMESSAGING-1421: ------------------------------------------ looking at the current trunk revision (r6622), the bug is still there. ClientCrashTest can be used to highlight the issues by uncommenting the session assertions. When the client crashed, on the server side, a connectionDestroyed event is notified on NettyAcceptor. In turn, this triggers a connectionDestroyed on the RemotingServiceImpl: -> the connection is removed from the RemotingServiceImpl connections list and is destroyed *but* its resources are never cleaned up. Since the connection is no longer in the list, the connection TTL will have no effect. Reading the code, it seems it is expecting to receive a connectionException on the RemotingServiceImpl if there is a failure on the connection but that is not the case. This event is never triggered by NettyAcceptor. I'll check with Trustin if it is a regression on Netty. For now, the only solution I came up with is to *never* destroy the connection when it is closed and let it be cleaned up on the connection TTL. If the users close their connection properly, there won't be side-effect (resources will be cleaned up as part of the connection close process). If the users do not close their connection, the resources will be held up on the server until the connection TTL is hit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira