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.
