[ http://jira.jboss.com/jira/browse/JBMESSAGING-1230?page=comments#action_1... ] Kenny MacLeod commented on JBMESSAGING-1230: -------------------------------------------- Can I also suggest that the scope of the problem be widened to the case where both nodes are shut down, leaving unprocessed messages in the database, and then only one node is restarted. Currently, this leaves the other node's messages orphaned until that node is restarted, but in some cases that node may never be restarted - in the case of a hardware failure, for example. Some kind of orphan reclaimation task would seem advisable? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1230?page=comments#action_1... ] Kenny MacLeod commented on JBMESSAGING-1230: -------------------------------------------- I wouldn't be particularly happy with that solution, for two reasons: a) I may not want to start another node. Say I have a cluster of two machines, and I want to replace one of them. The proper way to do this is to add a third node, then remove one of the old ones, so that at all times at least 2 nodes are present. In this scenario, the node that is removed is gone, and will not be replaced. b) I auto-generate my ServerPeerIDs based on hostname, since I don't want to manually manage these obscure integers. Forcing nodes to use a certain ID in order to reclaim orphan messages just doesn't work with this operational model. So in some perfectly common situations, re-use of the ServerPeerID is not practical or desirable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1230?page=comments#action_1... ] Phillip Thurmond commented on JBMESSAGING-1230: ----------------------------------------------- Just to address a couple of points from the forum posts at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=110632 ----snip "Shutting down a node in the cluster is quite different from failing over. With a shutdown, it is likely the sys admin is just taking the node down temporarily and will restart it again shortly. In this case we *do not* want another node to take over and merge the queues of the node that is being taken down." "Imagine the pathological case where the sysadmin takes every node in the cluster down one by one. By the time the sysadmin takes down the last node in the cluster, that node will have merged in *all* the queues from the other nodes! Not only will this be slow, but it means that when the cluster is brought back up, only one of the nodes (the last one to be taken down) will have all the messages." ----snip I would argue that this behavior would be desirable in some common situations. Specifically, if the sysadmin wants to do maintenance on several nodes without interrupting service to any of the clients. Merging all the queues to one server might be desirable here since this type of maintenance is usually done during off-peak hours. Also, without being too contrived, I think there are failure scenarios (ie, all nodes losing network connectivity except one) which could result in the above situation occurring even with the current failover implementation. I can't speak for what's happening in the implementation when these different scenarios occur, but from a sysadmin's perspective they seem like very similar events which should be handled consistently. Maybe it would be possible to add a flag which specified that a shutdown should be treated as a failover event? That way it would be an option for those who wanted this functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1230?page=all ] Tim Fox updated JBMESSAGING-1230: --------------------------------- Issue Type: Bug (was: Feature Request) Fix Version/s: 1.4.0.SP3.CP02 1.4.1.beta2 (was: Stable branch) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1230?page=comments#action_1... ] Tim Fox commented on JBMESSAGING-1230: -------------------------------------- It's already in the docs. Search for ""enableFailoverOnShutdown" as I mentioned in the previous comment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira