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-generation-tp4693781p4693983.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
