activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <gary.tu...@gmail.com>
Subject Re: [VOTE] Apache ActiveMQ 6.0.0 (RC3)
Date Wed, 01 Apr 2015 11:23:59 GMT
On 28 March 2015 at 19:02, artnaseef <art@artnaseef.com> wrote:
> Hey Gary - in all the discussion, I missed this response, so forgive my slow
> response.
ditto :-)

>
> First, let me apologize for my use of the word "take" - it sounds it was
> read as an attack or accusation, and that was not my intent.
Accepted.

>I simply meant, "why is it important that HornetQ be called AMQ-6?"
>
> On the point that AMQ needs a v6, can you tell me why that itself is
> important?  Please be specific - I have seen many comments made that really
> are just restatements of the line that ActiveMQ needs a new broker, but no
> real detail to discuss behind that.
>
I can cite a few examples but the full story is in jira:
1) durable subs should be modelled as queues. They are not in 5.x. Dealing
with slow durable consumers and large backlogs has had loads of issues in
the past[1] and still has issues like across networks.

2) Cursors introduce a cache synchronisation problem.
I think that is mostly resolved but it permeates most of the core
dispatch logic and store interface.
It is more complex and error prone than necessary imho [2]. Cursors
model consumers but I think there is a better way. HQ models producers
in paging. Apollo collapses the index, both benefit from a single core
queue abstraction.

3) Priority support - should be modeled as multiple queues.
the cursors and stores and dispatch logic collude to do priority
support in 5.x - it has been error prone [3]

4) scalability; threading model, zero copy dispatch, locking and
contention. I won't site specjms again, but I burned a lot of cycles
to try and get the best numbers for the folks that ran those tests.
The results are good, but we were blown out of the water by a better
architecture. It is not a mickey-mouse test btw.

> When I look at those statements, I have
> to balance them with my belief of ActiveMQ's popularity, market penetration,
> and ongoing efforts to add ActiveMQ into companies.
>
Exactly. What a existing user wants most from a messaging solution is
stability. While each of the points above are fixable, they are all
high risk and taken together they are a huge body of work. As a result
of evolution there is much complexity; it always surprises me the
degree to which one or two of the 4k tests fail with some seemingly
unrelated change. The 4k tests are one of the most valuable parts of
activemq. They embody hundred of use cases. Keeping them all working
and doing major surgery is getting more difficult all the time.

> Also, have you considered the possibility that naming Apollo "AMQ-6" has
> contributed apparent lack of innovation?
>
I agree. I think the 6.x moniker is a problem. I am in favour of using
a 10.0.0.M1 name for the code donation.

It puts clear daylight between it and 5.x, leaving 5.x room to evolve.
But more importantly imho, it gives activemq clear direction. I think
the user community will eventually tell us if v10 can take over the
5.x mantle.

> In other words, isn't it a concern that it will be hard to encourage innovation on the
current product,
> ActiveMQ 5.x, as long as there's a promise of a very different ActiveMQ 6.x?
>
I think the innovation that is possible in 5.x is limited by
 a) its architecture and evolution.
 b) the need for stability, the large user base and numerous use cases.

There is plenty of room to improve however. I expect that to continue.

> I know that even causes me to pause.
>
Would version 10 allow you to pause and be happy with 5.x for the next
few years, till 10.x gets a chance to bed in?


[1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20AMQ%20AND%20status%20%3D%20Open%20AND%20text%20~%20%22Durable%22
[2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20AMQ%20AND%20text%20~%20%22cursor%22
[3] https://issues.apache.org/jira/issues/?jql=project%20%3D%20AMQ%20AND%20text%20~%20%22priority%22

Mime
View raw message