activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Shannon <christopher.l.shan...@gmail.com>
Subject Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap
Date Wed, 29 Nov 2017 19:10:23 GMT
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.tully@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.suconic@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 <tbain@alumni.duke.edu> wrote:
> >
> > > On Nov 21, 2017 3:00 PM, "Clebert Suconic" <clebert.suconic@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message