Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

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

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


> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

gtully
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 <[hidden email]>
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 <[hidden email]> wrote:
>
> > On Nov 21, 2017 3:00 PM, "Clebert Suconic" <[hidden email]>
> > 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

christopher.l.shannon
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> wrote:
> >
> > > On Nov 21, 2017 3:00 PM, "Clebert Suconic" <[hidden email]>
> > > 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

clebertsuconic
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 <
[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> wrote:
> > >
> > > > On Nov 21, 2017 3:00 PM, "Clebert Suconic" <
> [hidden email]>
> > > > 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

tabish121@gmail.com
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 <
> [hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]>
>> wrote:
>>>>> On Nov 21, 2017 3:00 PM, "Clebert Suconic" <
>> [hidden email]>
>>>>> 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/

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

clebertsuconic
On Wed, Nov 29, 2017 at 2:17 PM, Timothy Bish <[hidden email]> wrote:

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


Yes.. I know.... the vote should be private or public on the dev list
since it is up to the PMC?


Since the discussion is public, I would say dev-list... but wanted to make sure.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

tabish121@gmail.com
On 11/29/2017 02:23 PM, Clebert Suconic wrote:

> On Wed, Nov 29, 2017 at 2:17 PM, Timothy Bish <[hidden email]> wrote:
>> 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.
>>
>
> Yes.. I know.... the vote should be private or public on the dev list
> since it is up to the PMC?
>
>
> Since the discussion is public, I would say dev-list... but wanted to make sure.
>
There's generally few reasons that something needs to be private, this
seems like something that is worthy of full community input.

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