[
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.
Client failover support if one node of a cluster is cleanly shut
down.
----------------------------------------------------------------------
Key: JBMESSAGING-1230
URL:
http://jira.jboss.com/jira/browse/JBMESSAGING-1230
Project: JBoss Messaging
Issue Type: Feature Request
Reporter: Phillip Thurmond
Assigned To: Tim Fox
Fix For: 1.4.0.SP3.CP01
If one node of a cluster fails in someway, the client will attempt to failover
transparently. However, if one node is shutdown cleanly, the client will not
automatically failover to another node in the cluster. This functionality would be very
useful for "rolling upgrades" where a portion of the cluster is left up while
the other nodes are being updated.
--
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