This discussion has been open for 15 days. IMO we should move ahead with whatever is the next step. Vote probably?
On Wed, Nov 29, 2017 at 2:10 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > 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 > > > > > > -- Clebert Suconic
