activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tabish...@gmail.com>
Subject Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap
Date Wed, 29 Nov 2017 19:17:22 GMT
On 11/29/2017 02:13 PM, Clebert Suconic wrote:
> This discussion has been open for 15 days. IMO we should move ahead with
> whatever is the next step.  Vote probably?

Yes, the PMC needs to vote on something, a discussion thread isn't a 
vote.  I'd suggest putting together a reasonably detailed proposal of 
what you see as the future plan should be and start a vote.

>
> 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
>>>>

-- 
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/


Mime
View raw message