Live data from Hacker News

ActiveMQ: Not ready for prime time

goodstuff.im

31–40 of 93 posts

Re: ActiveMQ: Not ready for prime time

#32

Earlier quoted context omitted.

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 fou…

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.

Re: ActiveMQ: Not ready for prime time

#33
post #13

How does activemq compare to zeromq?

activemq should offer higher level guarantees about reliability. zeromq is simpler. you can argue that activemq has things you will probably end up implementing yourself on top of zeromq, or that zeromq has less to get wrong... another way of saying the same thing, which illustrates the cultural differences: - activemq is intended to be used in "the enterprise". it tries to implements a logical ideal, which is a reli…

"i might as well learn" <-- that's why I read HN -- learn something new every day :)

Re: ActiveMQ: Not ready for prime time

#34

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…

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

Re: ActiveMQ: Not ready for prime time

#35

Does anyone have recommendations for resources on messaging/queueing basics? I'm look for something on the basic patterns (pubsub, broadcast... ?) and basic considerations to be aware of.

http://www.eaipatterns.com/ perhaps?

That looks helpful- thanks!

Re: ActiveMQ: Not ready for prime time

#37

Does anyone have recommendations for resources on messaging/queueing basics? I'm look for something on the basic patterns (pubsub, broadcast... ?) and basic considerations to be aware of.

As far as considerations to be aware of, Second Life posted their message queue evaluation notes: http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Not...

This looks helpful, too. Thank you!

Re: ActiveMQ: Not ready for prime time

#38
post #13

How does activemq compare to zeromq?

zeromq does not persist messages so you can lose them and need to adjust your infrastructure around this. If you are used to network programming that should be fine, just build persistence in to your protocol where you need it, ie reply after you have committed to persistent storage.

Re: ActiveMQ: Not ready for prime time

#39

Does anyone have recommendations for resources on messaging/queueing basics? I'm look for something on the basic patterns (pubsub, broadcast... ?) and basic considerations to be aware of.

The getting started guide for RabbitMQ is well done: http://www.rabbitmq.com/getstarted.html The ZeroMQ guide goes into more indepth: http://zguide.zeromq.org/page:all

Re: ActiveMQ: Not ready for prime time

#40
post #34

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…

"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.)
Post reply on HN