Hacker News Reader

Comment by lkesteloot | Hacker News Reader

I used ActiveMQ in a large production environment for two years. It's by a large margin the worst piece of software I've used professionally. You wouldn't believe the number of very serious problems we had with it (including some mentioned here, like negative queue lengths, but mostly broker crashes, missing or wrong documentation, outright broken features, serious threading issues, and poor performance). If anyone's not convinced, just peek at the source code. It's frightening.

We ended up writing a new queuing system from scratch in a month, and in its first week it was already more stable, performant, and bug-free than ActiveMQ.

View on HN

This is refreshing to read. I worked with ActiveMQ for about 2 years, and had nothing but problems with it. We probably lost thousands of dollars in sales because of lockups, corruptions, etc. I always assumed that we were "just doing something wrong" (which we probably were in many cases), but we were basically using out-of-the-box configurations and Spring for the JMS support. I'm glad to hear that I'm not the only one that has had problems with it. I assumed it should be pretty stable since it's an Apache project, but I have to agree that the source code is almost incomprehensible.

The thing we found is that when it crashed under load, it could take over 24 hours to consistency check and rebuild its queues on-disk. Insane for a highly-available environment.

This is why you should NEVER let an architect choose your software - ALWAYS the sysadmin who will actually be on-call to support it should have the final say.

"ALWAYS the sysadmin who will actually be on-call to support it should have the final say"

Ah, if only that happened in the real world...

Why'd you write one from scratch instead of just using JBossMQ or HornetQ or something? ActiveMQ is far from being the only open-source message queuing product, even if you only consider JMS compliant ones.

This was two years ago. JBossMQ was being rewritten and the new version was too immature. I don't remember HornetQ. We investigated RabbitMQ, which seemed good but still a bit young to bet our company on. We also needed some interesting features that none of these provided. In the end writing our own was the best decision we made my whole time at that company -- it paid dividends the rest of my time there.

I just found a thread I started about ActiveMQ and scaling:

http://activemq.2283324.n4.nabble.com/6000-ActiveMQ-clients-...

Note the last message there. 36,000 threads when using NIO! And these answers were from the people commercially supporting ActiveMQ (FuseSource). I never did find out (on that thread or elsewhere) whether ActiveMQ has ever been used in a situation that large. I suspect it hasn't.

This was two years ago. JBossMQ was being rewritten and the new version was too immature.

Ah, ok... gotcha. Didn't realize the time-frame.

I don't remember HornetQ.

It's fairly new... basically the successor to JBossMQ. It is reputed to be blazing fast though. I've been experimenting with it, but haven't used it in anger.

We investigated RabbitMQ, which seemed good but still a bit young to bet our company on.

Fair enough.

Hi - this is pretty damning. We're currently building an application that uses ActiveMQ but I could switch to a different broker if I thought it was justified. Do you remember which version you were using?

I believe it was 5.0 and 5.1.

I experienced similar issues with these versions.

We've had nothing but problems with ActiveMQ and we've been using it for 4-5 year now. We've been slow on making the decision to move to a different open source implementation because it is difficult to test this kind of software. I mean, ActiveMQ appears to work fine in tests, but in production, lock-ups and storage leaks happen on monthy basis. We need simple functionality, peristent queues in their simplest form. HornetQ seems like a good candidate. I'd appreciate if anyone could share their experience with it.

what version you working with?

Currently, 5.5.0. And we have used every release in the last 4 years, from 4.6 to 5.5.0.

Its surprisingly easy to write a messaging system that meets your requirements. Having a messaging system that meets every use case is extremely difficult. ActiveMQ is deliberately highly configurable - to try and address this - ActiveMQ is now stable and performant - with a high degree of fault tolerance built in. The things you should care about - like what happens if you loose the network, a disk etc are automatically taken care of with ActiveMQ.

I had this exact experience about four years ago. Spent way too long dealing with their buggy code, wrote our own in a few weeks and everything was much easier from then on.

"We ended up writing a new queuing system from scratch" <-- If it's good, why not open-source it? I'm sure there are many others who have use for a good queuing system.

They're in the process of doing that. (I no longer work there.)

Two years? Why'd you stick with it so long? ;)

Reply on news.ycombinator.com