This doesn't really work for topics; you need to get the new messages to collect on b2 while the old consumer drains b1, and only then have the old consumer disconnect and reconnect on b2; you can't have the consumer simultaneously connected to both b1 and b2. (Obviously this is only for durable subscriptions; non-durable ones won't work even if you figure out how to get this to work for durable ones, as described earlier in the thread.) You also probably don't want messages to get pulled from b1 to b2, since that will result in reordering of the messages; ideally you'd read all of the messages from b1 (in order) and then read all of the (newer) messages from b2 (also in order). I actually think your best bet would be:
1. existing b1 is planned to be deprecated 2. introduce the new broker, b2, but do not network it to any other brokers 3. introduce b2's hostname/IP into clients' failover URIs as the low-priority host 4. have all consumers currently on b1 establish a durable subscription on b2 and then immediately disconnect; no messages are consumed 5. deprecate b1 6. disconnect b1 from all networked brokers 7. connect b2 to all networked brokers; messages published elsewhere in the network will now collect on b2, waiting for the consumers to come consume them 8. switch all publishers to b2 9. as consumers finish draining b1, they can be rolled over to b2, where they'll begin consuming messages from it in order 10. once all consumers have rolled over, shut down b1 Step 9 could be facilitated by having a broker that has been deprecated (Step 4, needs to be implemented) refuse producer connections (and force disconnection/failover of producers) immediately, and refuse consumer connections (and force disconnection/failover of consumers) for any destination/subscription that has no messages. Otherwise you have to leave all consumers on b1 until the last destination has its last message read. This process doesn't handle: 1. Scheduled messages 2. Non-durable topic subscriptions 3. Destinations that have messages but no currently-connected consumers 4. DLQed messages (though you could argue that that falls under #3); note that DLQ consumers would have to be left on b1 until all other messages are consumed, because an empty DLQ could become non-empty later if a consumer failed to process a message 5. Anything (e.g. embedded Camel routes) that moves messages from one destination to another within the broker, because that could result in an empty destination whose consumers have been rolled over to b2 becoming non-empty later On Thu, Mar 12, 2015 at 1:14 PM, James A. Robinson <j...@highwire.org> wrote: > On Thu, Mar 12, 2015 at 8:58 AM, Tim Bain <tb...@alumni.duke.edu> wrote: > > > And there would need to be a change > > to allow a non-durable subscriber to disconnect from the old broker > without > > unsubscribing the consumer and to resume that subscription once the > > connection is made to the new broker (and obviously this would have to be > > implemented so that it only behaves that way when that subscription is in > > transition and no at other time). > > > > I think I was assuming a flow like this: > > (0) existing b1 is planned to be deprecated > > (1) introduce the new broker, b2 > > (2) old consumers still read b1, add new consumers to read b2 > > (3) start switching publishers to point to b2, and add a network connector > on b1 forwarding to b2 > > (4) allow b1 to be drained by the old consumers and by pulls from b2 > > (5) shut down the old consumers and b1 > > Is that flawed? >
