Import/export of the stores still won't roll a non-durable topic subscription from the old to the new broker, which means that when the consumer disconnects from the old broker it will lose all unconsumed messages as well as any messages produced between when it disconnects from the old broker and when it connects to the new broker.
Also, did the import/export work for the in-memory store, or just KahaDB/LevelDB? On Mar 10, 2015 6:03 AM, "Gary Tully" <gary.tu...@gmail.com> wrote: > note - as part of apollo - there was some tooling around export/import > of message stores. > apollo does import and 5.x does export [1]. > I guess it would not be much work to provide a 5.x import tool. > Scheduler store is still an outlier though. > > [1] > https://github.com/apache/activemq/blob/5667e4ddcc44e1331cafea2c1537afeaa550a2cd/activemq-console/src/main/java/org/apache/activemq/console/command/store/StoreExporter.java > > On 9 March 2015 at 19:03, Tim Bain <tb...@alumni.duke.edu> wrote: > > This solution works in certain situations, but there's currently no way > to > > cleanly migrate consumers to the new broker in all situations. Scheduled > > messages and non-durable topic subscriptions are two examples of cases > > where simply standing up a new broker and having all clients move to it > > isn't really a viable option at present. There are a couple of threads > > about the possibility of adding features to smoothly roll clients off of > > one broker and onto another one (most recently a thread between me and > > Kevin Burton and Art a month or so ago) if anyone wants background on the > > subject... > > > > On Mon, Mar 9, 2015 at 10:27 AM, Timothy Bish <tabish...@gmail.com> > wrote: > > > >> On 03/09/2015 11:54 AM, James A. Robinson wrote: > >> > >>> On Fri, Mar 6, 2015 at 6:07 AM, underflow <underf...@async.eu> wrote: > >>> > >>>> - Another idea was to create a network of brokers with the original > >>>> instance > >>>> (w/ kahadb persistence) and the new instance (w/ leveldb persistence) > + > >>>> resending all content, if required... > >>>> > >>> I'll be curious to see what advice you get. I'm new to activemq, but > this > >>> sounds like a very reasonable approach to me. I'd set up a cluster > with > >>> the new backing store and migrate clients to it. Once I was happy the > old > >>> one is not needed I'd turn off the transport connectors and let it > forward > >>> any remaining data to the new cluster. > >>> > >>> Jim > >>> > >>> This is in fact a reasonable solution. This is also recommended when > >> upgrading brokers even when using KahaDB so that messages from an older > >> KahaDB version can be drained to the new broker. > >> > >> -- > >> Tim Bish > >> Sr Software Engineer | RedHat Inc. > >> tim.b...@redhat.com | www.redhat.com > >> skype: tabish121 | twitter: @tabish121 > >> blog: http://timbish.blogspot.com/ > >> > >> >
