Thank you for your comments, Jakub. What’s important to me is you pointing out that there are two distinct communities here. That’s my read as well.
At Apache we don’t shove two communities together that aren’t necessarily sure they wanted to be shoved together in the first place. A majority of the PMC can’t force the minority to do things like this, or the board steps in. We have means and mechanisms to support >1 community; it’s called new projects. At the ASF they can arrive through Incubation and/or through an experimental direct-to-TLP initiative for projects that meet a certain criteria/bar. It’s 1 PMC per community at the ASF - years ago we supported things called “umbrella projects” until we found out that there are loads of issues with them. You don’t see umbrella projects too much more at the ASF. Given the above and given Jim’s recent reply else-thread, the ActiveMQ PMC needs to develop a plan for recognizing what many of us have already; that there are 2 communities here and as such there needs to be 2 projects (HornetQ->Incubation); or a plan for how there isn’t 2 communities and what specific steps there are for that to be true. Cheers, Chris -----Original Message----- From: Jakub Korab <[email protected]> Reply-To: <[email protected]> Date: Monday, March 30, 2015 at 3:58 AM To: <[email protected]> Subject: Re: [DISCUSS} HornetQ & ActiveMQ's next generation >I thought I'd add my bit, and this point in the thread seemed as good >any. My background's a bit different to the other people here in that >I'm not a committer, but definitely consider myself part of the broader >community and work with ActiveMQ on pretty much a daily basis (so have >skin in the game), but am not employed by any particular vendor. > >The need for a new broker architecture is pretty strong. ActiveMQ 5 just >doesn't make best use of the resources that you give it - disk, network, >CPU cores, whatever - and people end up jumping into clustering much >sooner than they should. Having said that, performance isn't the be-all >and end-all, otherwise people would switch to whatever competing product >is fastest. There's loads of goodies within ActiveMQ that aren't in any >equivalent broker, and a lot of that value and work that's been done >ought to get carried over (replicated LevelDB as a random example). What >users want to see in whatever the next version of AMQ is, is the >features that they're currently using. > >What I understand has always been the intent (from reading this mailing >list for some time) was that all the good bits get carried over to a new >core. If someone has already written a new core and donated it, as has >happened, that's awesome. What I'm seeing through the JIRAs is that >there are definitely two groups of distinct committers working on what >appears to be two products (hence the talk about incubation etc. - which >I hope ends up not happening). Splitting the HQ donation by name to a >new project, and maybe merging the two at some point, seems out of line >with the original intent and partitions the set of developers further. >Cross-project cooperation on something as complex as this is a nice but >ultimately unlikely-to-be-realised idea; under one name it has a strong >chance of working out. As Rob has pointed out, rewriting a core based on >the good ideas of HQ, would still require loads of work to get it do all >the things that the HQ core already does - and people/time to do it. > >Assuming that there is consensus around these points (which there >doesn't sound like there necessarily is), the idea of a separate line of >development (as is currently taking place) with milestone releases >sounds like the way forward. What needs to support it from a community >point of view is: > > * Clarity to users around what activity is going on (I get asked this > all the time). To that extent, a feature-compatibility table needs > to be drawn up and left on the wiki, that way at least from an > outsider's view you can see what the current state of play is and > what the future plans are. > * Publicly accessible architecture/developer documentation around the > HQ core. It's hard to contribute to a project that is "kindof like > the old thing, but completely different" with no pointers. > * Interoperability between the 2. At the network of brokers level at > the minimum (maybe already there - see my first point), and perhaps > the at the store level. > >What I think makes sense in the future is that ActiveMQ 5 doesn't need >to go away, it stays in a kind of maintenance mode++, with the big new >features building on the newer core. I'm thinking a bit like what >happened with Struts 1.x relative to 2.x. The commits just dropped off >after a while, as the bulk of the work moved to the 2.x core (which also >came from an external donation - WebWork). > >Whatever happens, I look forward to working with and contributing to >ActiveMQ in the future. > >Jakub > > >On 28/03/15 21:09, Rob Davies wrote: >> Art - I hope these are the questions you thought haven't been answered. >>This is my POV only. >>> On 27 Mar 2015, at 18:58, artnaseef <[email protected]> wrote: >>> >>> I don't agree with the presumption that ActiveMQ *needs* a *new* >>>broker. >> I implemented the architecture for ActiveMQ 1.0 (before it was >>detonated to Apache) - and since then Hiram and I have pretty much >>alternated redesigning the broker with each major version. ActiveMQ 5 >>was designed primarily to address the use case that some users wanted >>really long term message persistence (hence the message cursor >>implementation). >> Message brokers get compared on a relative small set of features - >>which boil down to usually straight throughput and scalability. The >>ActiveMQ threading model is quiet heavy - there's a lot of context >>switching as commands are passed from top to storage - and a lot of >>synchronisation along the way. To compete on throughput and scalability >>- a revamp is required. Hiram wrote Apollo with the hope it would be >>ActiveMQ 6. Technically Apollo is really good - it has really efficient >>threading model, no sync points and is completely asynchronous. The >>reason Apollo didn't gain traction is because it was written in Scala - >>actually only a couple of folks attempted to get involved. >> >> So writing a new architecture isn't particularly hard - probably a few >>months - but making sure it can handle all the edge cases will take >>years. Adding a new feature or fixing a bug in ActiveMQ 5 can take weeks >>- and that's because of all the test cases you have to pass to ensure >>you don't introduce a new bug whilst "fixing" something. Tinkering >>around the edges of the broker is relatively straight forward however. I >>think it's true that only a small number of committers tackle broker >>issues in ActiveMQ 5. >> >> HornetQ is asynchronous, built on top of netty (so the TCP >>implementation is extremely fast) but more importantly it's been around >>for a while and looks mature - which is why I assume it looks appealing. >>All the hard work involved in bedding in a new architecture has been >>done. >> >>> Nor >>> with the argument that it will die out if it doesn't get one. >> I agree. users really seem to like ActiveMQ because it is so flexible! >>However, there are a lot of areas where I wish ActiveMQ played a bigger >>role - like infrastructure messaging or IoT - which is why Apollo was >>written wasn't it? It's a shame a lot of people were put of by Scala - >>me included. It's impossible to gauge what will happen to ActiveMQ, but >>there is demand for messaging that AotiveMQ isn't even considered - and >>I think that's a shame. >> >>> Whole-sale replacement is hard. I worked in a company that *still* >>>uses >>> technology dating back to 1980 because several efforts to whole-sale >>>replace >>> the existing platform failed. That approach is hard. Note that I am >>>not >>> arguing that it's impossible, but this does make me concerned that >>>even with >>> the AMQ-6 name, HornetQ may fail to replace ActiveMQ - even as it >>>continues >>> as a completely successful product of its own. >>> >>> With all of that said, if it proves that ActiveMQ dies out without a >>>new >>> broker, I am alright with that. As mentioned before, if HornetQ takes >>>over >>> the market, I don't see that as a bad thing and look forward to the >>> opportunity to contribute there, or move on to other things. >> We have an opportunity to take the best of both implementations and >>make something compelling - and doing something bold gets attention - >>and we can grow a community of developers around that. It would be great >>if you could help drive that too. >>> >>> >>> -- >>> View this message in context: >>>http://activemq.2283324.n4.nabble.com/DISCUSS-HornetQ-ActiveMQ-s-next-ge >>>neration-tp4693781p4693983.html >>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. >
