After reading the discussion and thinking about it I think I am on board with going with ActiveMQ 6.
What's the next step with this? Do we want to propose a vote or keep the discussion open longer? On Thu, Nov 23, 2017 at 3:09 PM, Gary Tully <gary.tu...@gmail.com> wrote: > I think ActiveMQ needs a roadmap for sure and I think Artemis is the future > for a bunch of technical reasons. > > Without a clear direction going forward we will loose adoption because I > don't know anyone who likes making a choice. > > If you are an existing ActiveMQ user there should be a clear path forward. > If you are peeking at ActiveMQ for the first time you should find a vibrant > project. > > To avoid confusion, moving forward with ActiveMQ6 looks like the simplest > solution. > > That implies migration but also a step migration because there is a new > architecture. > > I would propose that the Artemis mainline becomes ActiveMQ 6.x. > Continuing the frequent release cadence of Artemis, any outstanding > migration issues can be promptly catalogued and addressed. > > Gary. > > On Thu, 23 Nov 2017 at 05:41 Clebert Suconic <clebert.suco...@gmail.com> > wrote: > > > The documentation does talk about those things. Migration guide is just > a > > quick guide on how to migrate but it does not replace the documentation. > > > > There was some good suggestions you made here as to tools to move > > configuration automatically. But that’s not a requirement to make any > > progress. We won’t ever get anuwhere if we aim for perfection as there > will > > always be space for more. Nothing in life is perfect. > > > > Tools and features I think it’s orthogonal to the discussion about the > > direction. > > > > On Wed, Nov 22, 2017 at 10:49 PM Tim Bain <tb...@alumni.duke.edu> wrote: > > > > > On Nov 21, 2017 3:00 PM, "Clebert Suconic" <clebert.suco...@gmail.com> > > > wrote: > > > > > > > Another thought - having both brokers long term seems redundant as > > there > > > is > > > > a huge amount of overlap, and I believe the intent (please correct me > > if > > > > this is wrong) is eventually to have Artemis superset all of the > *key* > > > > functionality from AMQ 5.x. > > > > > > I think all the features are covered at this point. The one exception > > > is Retroactive Consumers.. however this could be done with browsers > > > and paging. > > > It still on my personal list of improvements I want to make. I could > > > make it happen sooner with some demand.. So I don't think it blocks > > > anything going forward. > > > > > > The other feature that has been brought a lot of times.. is virtual > > > topics.. however with the address model in Artemis.. it's not needed.. > > > as virtual topic was a way to emulate a queue within a topic, which is > > > pretty much what we have on the address model. > > > > > > > > > > > In order to facilitate a move, users of AMQ 5.x are going to need a > > > smooth > > > > transition. Note that I don't mean to say it has to be seamless, > just > > > that > > > > it has to be smooth - easy enough to understand and execute. > > > > > > > > > > > Let me pose some questions here that may help move this forward: > > > > > > > > - Do we know what it takes to migrates customers from AMQ 5.x to > > > Artemis? > > > > > > > > > https://activemq.apache.org/artemis/migration.html > > > > > > ^^ It's in good shape IMO already. > > > > > > > > > That guide has lots of good information, but it explicitly punts on the > > > question of how to migrate a cluster that has existing unconsumed > > messages. > > > Does a migration guide for that subject already exist? If so, let's > link > > to > > > it; if not, I don't think we're ready yet. > > > > > > There are two possible ways to migrate when messages are pre-existing: > > > either you take an outage and convert the messages store somehow, or > you > > > network the old and new brokers but have clients use only the new > broker, > > > and you configure the brokers so that all of the messages flow from the > > old > > > broker to the new one without downtime. Note that the second approach > > won't > > > migrate scheduled messages, so it might be necessary to use a hybrid > > > approach depending on the use case. Are Artemis and ActiveMQ capable of > > > being networked together to allow the second approach? I've always > > assumed > > > that it could be done since Artemis supports OpenWire, but I've never > > heard > > > anyone say it was possible. I think we'd want the migration guide to > > talk a > > > bit about options for how to perform the actual operational migration, > > not > > > just how to configure Artemis to make it behave similarly to ActiveMQ > or > > > HornetQ (though that's important too, and the guide does that well). > > Also, > > > the guide should talk about what happens if a user wants to migrate > when > > > their broker contains more messages than will fit into Artemis's > memory, > > > since it's possible that some users might be in that situation. > > (Hopefully > > > not many people, though!) > > > > > > Also, I don't see any discussion in the guide of SSL transports even > > though > > > a number of other protocols (both network and application) are > mentioned, > > > so that looks like something else that should be added. > > > > > > > - Do we have a comprehensive list of features that will remain > > > supported? > > > > - Do we have a list of features that will not be retained? > > > > > > We had a few discussions in the past... there could be minor features > > > still needed.. but it's getting better each day as users needed new > > > functionality. > > > > > > The community aspect from the apache activemq community certainly > > > improved the software. > > > > > > IMHO ActiveMQ Artemis is good enough that it can be improved as needed > > > when missing points are found.. being an AMQ 5 missing feature or > > > anything else that users will need. > > > > > > > > > I don't think this bit addresses the last two questions that Art > raised, > > > which are not "do we have everything we need and can we afford to wait > > for > > > a fix if we discover that something's missing?" but rather "do we have > a > > > written list of which features we're keeping and which if any we're not > > so > > > we can refer users to them?" > > > > > > > Hope this helps. I honestly don't have a strong opinion on the > > long-term > > > > vision here. With that said, I do have some strong thoughts on > > > > consolidation in the near-term and what's important in getting to a > > > > long-term vision. > > > > > > Artemis has been under works for 3 years and something now... > > > I am biased to speak about it as I work on it as part of my daily job > > > on this codebase.. but I have seen it getting better each day.. with > > > contributors from different companies. > > > > > > > > > I wonder whether we should provide some simple utilities to help users > > > migrate their config files. The guide makes it sound like they > correspond > > > closely, so it should be relatively easy to convert any parts that can > be > > > converted (automatically, or at least with user input) while also > > > highlighting any configuration that requires manual attention (which > > gives > > > us an opportunity to point the user towards documentation about the > > options > > > and any trade-offs that might come with them). That could also let us > > build > > > a JAAS config file for anyone who's using the Simple Authentication > > Plugin. > > > > > -- > > Clebert Suconic > > >
