Clebert (or anyone else familiar with bridges), Does the core bridge in Artemis support demand based bridging?
One feature I use in 5.x a lot to prevent unnecessary network traffic is to have consumers drive the message flow. I.e. if you have multiple brokers bridged together it doesn't make much sense for broker A to send messages to broker B if there are no current consumers on broker B (especially for topic subscriptions or non-persistent messages) On Fri, Dec 8, 2017 at 7:20 AM, Christopher Shannon < [email protected]> wrote: > https://github.com/apache/activemq-cli-tools has the main readme which > has some usage instructions. Version 0.1.0 has been released already. > > On Fri, Dec 8, 2017 at 7:18 AM, Christopher Shannon < > [email protected]> wrote: > >> https://github.com/apache/activemq-cli-tools/tree/master/ >> activemq-kahadb-exporter >> >> I created that tool a while back but it was my fault for not publicizing >> it more. We can advertise it on the new web site and as part of the >> migration strategy. It will export messages to XML from KahaDB and >> MultiKahaDB and can be filtered by destinations. It will also compress the >> XML file if desired. Artemis can then read in the messages from XML and >> write them to its store. The nice thing about this is the data can be >> imported into any existing Artemis store (it doesn't have to be a brand new >> store). >> >> MessageId can not be retained right now because Artemis does not support >> OpenWire as a format for storing messages and the CORE ids are different. >> (It only supports CORE and AMQP I think) The OpenWire messages in the >> KahaDB journal need to be converted to the CORE protocol in order to be >> imported into Artemis. However, I believe that the original messageId is >> at least added as a property to the CORE message so it could be referenced >> later. >> >> Before creating this tool I initially looked at seeing if it made sense >> for Artemis to support KahaDB as a store however when I researched it was >> clear that the Artemis journal has a lot of advantages over KahaDB (faster, >> has compaction and paging, supports replication...to name a few) so it >> doesn't make sense to support it. >> >> On Fri, Dec 8, 2017 at 12:14 AM, Matt Pavlovich <[email protected]> >> wrote: >> >>> FWIW- An offline KahaDB export / Artemis Journal import tool was an idea >>> I added to the wiki page Bruce setup. Maintaining messageId I think is the >>> most critical element, and we could leave behind things like incomplete >>> transactions, message groups, etc. >>> >>> >>> On 12/7/17 10:00 PM, Clebert Suconic wrote: >>> >>>> On Thu, Dec 7, 2017 at 9:57 PM Bruce Snyder <[email protected]> >>>> wrote: >>>> >>>> I have suggested a similar tool that will read the ActiveMQ 5.x XML >>>>> configuration and convert it to an equivalent Artemis config. I think >>>>> this >>>>> would be easier to create than making Artemis read ActiveMQ 5.x >>>>> configs. >>>>> >>>>> For some reason I thought that Artemis supported KahaDB, but I'm not >>>>> sure >>>>> where I got this. I thought I read it somewhere. I wonder how >>>>> difficult it >>>>> would be to make Artemis support KahaDB as it is still the fastest >>>>> message >>>>> store, correct? >>>>> >>>>> Artemis journal it’s faster. We don’t currently support KahaDB. >>>> >>>> >>>> >>>> >>>> Bruce >>>>> >>>>> On Thu, Dec 7, 2017 at 6:56 PM, Christopher Shannon < >>>>> [email protected]> wrote: >>>>> >>>>> Thanks for getting this started Bruce. >>>>>> >>>>>> The migration portion is going to be tricky and we need to discuss >>>>>> more >>>>>> >>>>> how >>>>> >>>>>> to handle it. Maybe we need to write a tool to help convert the old >>>>>> 5.x >>>>>> XML config to the Artemis config or update Artemis to be able to read >>>>>> a >>>>>> >>>>> 5.x >>>>> >>>>>> style config. Obviously not everything will translate directly so >>>>>> that >>>>>> would need to be figured out. >>>>>> >>>>>> For the datastore we have a tool that will export KahaDB to XML that >>>>>> can >>>>>> then be imported by Artemis but this could probably be improved even >>>>>> more >>>>>> to make it more automated. >>>>>> >>>>>> On Wed, Dec 6, 2017 at 4:19 PM, Justin Bertram <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Thanks, Bruce! >>>>>>> >>>>>>> >>>>>>> Justin >>>>>>> >>>>>>> On Wed, Dec 6, 2017 at 3:16 PM, Bruce Snyder <[email protected] >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> I have added the following statement to the first paragraph in the >>>>>>>> >>>>>>> wiki >>>>> >>>>>> page: >>>>>>>> >>>>>>>> The overall objective for working toward feature parity between >>>>>>>> ActiveMQ 5.x and Artemis is for Artemis to eventually become >>>>>>>> ActiveMQ >>>>>>>> >>>>>>> 6.x. >>>>>>> >>>>>>>> Bruce >>>>>>>> >>>>>>>> On Wed, Dec 6, 2017 at 2:02 PM, Justin Bertram <[email protected] >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Would it be possible to clarify what, if anything, will happen if >>>>>>>>> >>>>>>>> Artemis >>>>>>> >>>>>>>> achieves the described level of feature parity with ActiveMQ 5.x? >>>>>>>>> >>>>>>>> In >>>>> >>>>>> other >>>>>>>> >>>>>>>>> words, what is the goal of Artemis' feature parity with 5.x? I >>>>>>>>> >>>>>>>> think a >>>>>> >>>>>>> broader road-map like that would really help the community as they >>>>>>>>> >>>>>>>> could >>>>>>> >>>>>>>> look at the Artemis road-map and see that they can help achieve the >>>>>>>>> >>>>>>>> goal >>>>>>> >>>>>>>> (whatever that is) by helping to implement feature X or Y. >>>>>>>>> >>>>>>>>> >>>>>>>>> Justin >>>>>>>>> >>>>>>>>> On Wed, Dec 6, 2017 at 2:51 PM, Bruce Snyder < >>>>>>>>> >>>>>>>> [email protected] >>>>> >>>>>> wrote: >>>>>>>>> >>>>>>>>> I have created a page on the wiki for the Artemis Roadmap here: >>>>>>>>>> >>>>>>>>>> https://cwiki.apache.org/confluence/display/ACTIVEMQ/ >>>>>>>>>> ActiveMQ+Artemis+Roadmap >>>>>>>>>> >>>>>>>>>> The goal of this page is stated at the top: to identify the >>>>>>>>>> >>>>>>>>> outstanding >>>>>>> >>>>>>>> issues that must be addressed by Artemis in order to achieve some >>>>>>>>>> >>>>>>>>> level >>>>>>> >>>>>>>> of >>>>>>>>> >>>>>>>>>> feature parity with ActiveMQ 5.x. >>>>>>>>>> >>>>>>>>>> I encourage everyone to contribute to this page and to discuss >>>>>>>>>> >>>>>>>>> this >>>>> >>>>>> roadmap >>>>>>>>> >>>>>>>>>> on this list. >>>>>>>>>> >>>>>>>>>> Bruce >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> perl -e 'print >>>>>>>>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\ >>>>>>>>>> >>>>>>>>> "YC;VT*" >>>>>> >>>>>>> );' >>>>>>>> >>>>>>>>> ActiveMQ in Action: http://bit.ly/2je6cQ >>>>>>>>>> Blog: http://bsnyder.org/ <http://bruceblog.org/> >>>>>>>>>> Twitter: http://twitter.com/brucesnyder >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> perl -e 'print >>>>>>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\ >>>>>>>> "YC;VT*" >>>>>>>> >>>>>>> );' >>>>>> >>>>>>> ActiveMQ in Action: http://bit.ly/2je6cQ >>>>>>>> Blog: http://bsnyder.org/ <http://bruceblog.org/> >>>>>>>> Twitter: http://twitter.com/brucesnyder >>>>>>>> >>>>>>>> >>>>> >>>>> -- >>>>> perl -e 'print >>>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" >>>>> );' >>>>> >>>>> ActiveMQ in Action: http://bit.ly/2je6cQ >>>>> Blog: http://bsnyder.org/ <http://bruceblog.org/> >>>>> Twitter: http://twitter.com/brucesnyder >>>>> >>>>> >>> >> >
