On 28 March 2015 at 19:02, artnaseef <[email protected]> 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
