4 ms·

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 belie

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.

jsvaughan 15y ago
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?
- lkesteloot 15y ago
  I believe it was 5.0 and 5.1.
  - ShabbyDoo 15y ago
    I experienced similar issues with these versions.
mindcrime 15y ago
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.
- lkesteloot 15y ago
  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-td2361579.html 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.
  - mindcrime 15y ago
    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.
dsimms 15y ago
Two years? Why'd you stick with it so long? ;)
veyron 15y ago
"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.
- lkesteloot 15y ago
  They're in the process of doing that. (I no longer work there.)
gaius 15y ago
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.
- CrLf 15y ago
  "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...
andywhite37 15y ago
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.
txxxxd 15y ago
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.
jgracin 15y ago
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.
- rajdavies 15y ago
  what version you working with?
  - jgracin 15y ago
    Currently, 5.5.0. And we have used every release in the last 4 years, from 4.6 to 5.5.0.
rajdavies 15y ago
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.

jsvaughan 15y ago

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?

lkesteloot 15y ago
I believe it was 5.0 and 5.1.
- ShabbyDoo 15y ago
  I experienced similar issues with these versions.

mindcrime 15y ago

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.

lkesteloot 15y ago
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-td2361579.html 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.
- mindcrime 15y ago
  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.

dsimms 15y ago

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

veyron 15y ago

"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.

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

gaius 15y ago

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.

CrLf 15y ago
"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...

andywhite37 15y ago

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.

txxxxd 15y ago

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.

jgracin 15y ago

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.

rajdavies 15y ago
what version you working with?
- jgracin 15y ago
  Currently, 5.5.0. And we have used every release in the last 4 years, from 4.6 to 5.5.0.

rajdavies 15y ago

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.