Art, Sure, as currently implemented, non-durable topic subscriptions have that issue. What I'm saying is that to do a seamless transition from one broker to another, features would need to be built into the broker to transition the broker's state from the old broker to the new one. This would need to include topic subscriptions (durable and not), pending messages on all destinations, scheduled messages, etc. 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).
But I disagree that the right solution is to implement something outside the broker; in fact, I disagree that it's even possible to implement a full solution outside the broker as the broker is currently implemented. At best you'll get a partial solution where some things will work and some (like non-durable topic subscriptions) won't. To get it right, this needs to be a feature baked into the broker -- or at a minimum, certain changes need to be baked into the broker's API so they could be called by an external solution, if that's how we choose to do it. And to your point about network issues, you're absolutely right, but the client-broker interface should work correctly when there are no network issues (and replacing a broker during an upgrade is not a network issue, it's an entirely-predictable maintenance activity that ActiveMQ currently does nothing to support). Tim On Wed, Mar 11, 2015 at 9:59 PM, artnaseef <a...@artnaseef.com> wrote: > Non-durable topic subscriptions have that issue no matter what - lose the > connection and all unconsumed messages are dropped. And all messages > published while disconnected are also missed. > > Keep in mind too that Topics do not persist messages themselves in > ActiveMQ; > only durable subscriptions lead to persistence of the messages. > > Migrating from one broker to another, or even upgrading a single broker, > non-durable Topic subscriptions need a solution outside the broker. Of > course, given their nature, I hope the application is written in such a way > that missing those messages is not critical since otherwise the application > is going to have major problems (due to message loss) when there are > hiccups > in the network. > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Data-Migration-from-KahaDB-to-LevelDB-tp4692615p4693034.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
