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.

Reply via email to