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/ >> >>
