activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap
Date Wed, 29 Nov 2017 19:13:53 GMT
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.shannon@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.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
> > >
> >
>
-- 
Clebert Suconic

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