ActiveMQ: Not ready for prime time • Hacker News Board

Re: ActiveMQ: Not ready for prime time

#81

Post by rabbitmq » Fri, May 27, 2011, 8:37 AM UTC

andrewcooke wrote: post #23

veyron wrote: 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…

If you want to know what motivated the creation of RabbitMQ please read chapter 1 of Jason and Alvaro's book, "RabbitMQ in Action" - http://www.manning.com/videla/Videla_MEAPCH01.pdf

RabbitMQ's main motivation has been to make it easier to join systems together, scale your applications and manage complex environments. That is what messaging is for. Back in 2006, we felt there was a need for a good, stable and scalable open source licensed product that could compete with the incumbents.

Notice that I did not mention performance. RabbitMQ has good performance and it is used quite a lot in finance, but the majority of users are what you might categorise as "anyone using MySQL or Postgres".

Re activemq vs zeromq, I recommend reading "broker vs brokerless" on our blog.

Hope this helps.

Re: ActiveMQ: Not ready for prime time

#82

Post by rajdavies » Fri, May 27, 2011, 8:46 AM UTC

lucraft wrote: post #5

One thing I remember in particular from ActiveMQ was that it would often get itself into the state of having negative queue lengths.

That hasn't been the case for a long while

Re: ActiveMQ: Not ready for prime time

#83

Post by rajdavies » Fri, May 27, 2011, 8:47 AM UTC

jgracin wrote: post #70

lkesteloot wrote: post #14

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'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.…

what version you working with?

Re: ActiveMQ: Not ready for prime time

#84

Post by rajdavies » Fri, May 27, 2011, 8:52 AM UTC

BTW - David Pollak didn't talk to any of the ActiveMQ team at FuseSource - else we would have helped him out - he didn't speak to any of the execs either. Its a shame he doesn't allow comments on his blog.

Re: ActiveMQ: Not ready for prime time

#85

Post by dpw » Fri, May 27, 2011, 9:04 AM UTC

rabbitmq wrote: post #74

AmrMostafa wrote: post #50

Earlier quoted context omitted.

The RabbitMQ management plugin does provide an excellent command line interface. You download it along with its docs right from the management UI (/cli). Btw, I'm using RabbitMQ, and I love it. My needs do not include high load or high availability though so I can't speak for that. So what's nice about it? AMQP (you automatically get lots of tools, docs, "expectations", etc), very friendly and active mailing lists, s…

We have always accepted server patches via the mailing list: https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq... But it's true that the community has been much more involved in clients like Pika, for example. And yes we are planning to open up the bug tracker. A piece of advice for anyone doing an open source project - start with an open tracker, because opening up a previously closed tracker is a royal p…

And while we don't use github internally, people can and do submit issues and pull requests there:

https://github.com/rabbitmq

(N.B. we need contributors to sign a contributor agreement.)

David (rabbiteer)

Re: ActiveMQ: Not ready for prime time

#86

Post by jgracin » Fri, May 27, 2011, 10:32 AM UTC

rajdavies wrote: post #83

jgracin wrote: post #70

Earlier quoted context omitted.

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

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.

Re: ActiveMQ: Not ready for prime time

#87

Post by ghostganz » Fri, May 27, 2011, 11:21 AM UTC

I had a lot of trouble with the network-of-brokers feature in ActiveMQ a few years ago, which in the end forced us to switch to another solution.

In a later, simpler, project I had issues with ActiveMQ locking up after a certain number of messages, which was solved with an upgrade.

On a whole, I think the quality of ActiveMQ is lower than other open source projects with similar brand recognition, e.g. other popular Apache projects.

Re: ActiveMQ: Not ready for prime time

#88

Post by andrewcooke » Fri, May 27, 2011, 11:58 AM UTC

rabbitmq wrote: post #81

andrewcooke wrote: post #23

Earlier quoted context omitted.

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…

If you want to know what motivated the creation of RabbitMQ please read chapter 1 of Jason and Alvaro's book, "RabbitMQ in Action" - http://www.manning.com/videla/Videla_MEAPCH01.pdf RabbitMQ's main motivation has been to make it easier to join systems together, scale your applications and manage complex environments. That is what messaging is for. Back in 2006, we felt there was a need for a good, stable and scalabl…

http://www.rabbitmq.com/blog/2010/09/22/broker-vs-brokerless...

(thanks)

Re: ActiveMQ: Not ready for prime time

#89

Post by nvarsj » Fri, May 27, 2011, 1:58 PM UTC

As a counter point, I have used ActiveMQ for a pub/sub architecture and it worked great (millions of messages a day, which was benchmarked as only about 10% of potential on a single broker). We did treat it as an API rather than a deployable component though. We wrapped the broker in our own service architecture (you can instantiate a broker like any POJO) and disabled persistency. Queues were used only very lightly. So maybe we dodged a bullet there... :-).

Re: ActiveMQ: Not ready for prime time

#90

Post by prpatel » Fri, May 27, 2011, 5:34 PM UTC

nonrecursive wrote: post #11

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.

I would suggest getting the "Camel in Action" book from Manning. I always find that it's better to learn something that has real implementation behind it - you see the theory, now here's the code to do it.