Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ActiveMQ: Not ready for prime time

goodstuff.im

Post reply on HN
Print view View original

41–50 of 93 posts

Re: ActiveMQ: Not ready for prime time

#41

Post by gaius »

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…

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.

Re: ActiveMQ: Not ready for prime time

#42

Post by nonrecursive »

jhawk28 wrote: post #39
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.

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

Thanks. I've tried reading the zeromq guide before, but it was confusing because it used concepts that I wasn't familiar with and it didn't define the concepts. Also, its examples are in C, and I don't know C. The RabbitMQ one looks helpful, though

Re: ActiveMQ: Not ready for prime time

#43

Post by jpitz »

stonemetal wrote: post #36
veyron wrote: post #13

How does activemq compare to zeromq?

Activemq is a program that you can install and run, of a type often called message oriented middle ware. Zeromq is a library that provides abstractions on sockets. Basically they are unrelated.

You can, and we do, embed an ActiveMQ broker in an application.

They pass messages. They're fairly related.

Re: ActiveMQ: Not ready for prime time

#44

Post by rbranson »

marshray wrote: post #9
adamgravitis wrote: post #6

The thing I've found about message queues is that it's pretty unimportant what platform they're based on. I used to be tempted to go with ActiveMQ "because it runs on the JVM", but that turns out to be pretty irrelevant. No matter what your queue provider, you're most likely just using TCP sockets anyway, so don't think you need to be using Erlang just to take advantage of RabbitMQ. Yes, this means the MQ can basical…

What I've seen with RabbitMQ is that the memory usage can grow and grow. If it runs out of either committed RAM or address space, it crashes. I suspect this may be a feature of the open source Erlang VM that's improved in the pay-for-support version. Even though RabbitMQ pays the performance cost of bouncing everything off the disk, it's not quite recoverable from that type of crash. I'm sure my information is old, p…

Actually Erlang/OTP provides exactly the type of abstraction layer that's extremely useful for RabbitMQ's use case. It's specifically designed for consistent latency, predictable memory usage, and resilience under failure conditions. You know, basically the things that make an MQ worth using.

It was true that previously RabbitMQ could run out of memory and be unable to take more messages, but that changed in 2.0 and it will now swap messages to disk. Of course, then you pay the consequences of slow disks and can always run out of disk space, but nothing is invincible.

Re: ActiveMQ: Not ready for prime time

#46

Post by rbranson »

It's absolutely incredible that it can take so much effort just to make it run. ActiveMQ seems shiny and interesting on the outside, but the prolific number of war stories took it off my list.

In brilliant contrast, RabbitMQ is it-just-works software. It's a piece of infrastructure that works so well it practically just fades into the background. I couldn't imagine having to worry about a service in which the chief goal is to help alleviate reliability concerns.

Re: ActiveMQ: Not ready for prime time

#47

Post by vailripper »

andrewcooke wrote: post #17
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.

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

This is what I used to get up to speed on integration patterns. The book that the site is based on is very very valuable as well.

Re: ActiveMQ: Not ready for prime time

#48

Post by CrLf »

gaius wrote: post #41
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…

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

Re: ActiveMQ: Not ready for prime time

#49

Post by malkia »

nonrecursive wrote: post #42
jhawk28 wrote: post #39

Earlier quoted context omitted.

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

Thanks. I've tried reading the zeromq guide before, but it was confusing because it used concepts that I wasn't familiar with and it didn't define the concepts. Also, its examples are in C, and I don't know C. The RabbitMQ one looks helpful, though

ZeroMQ has examples for many languages. Try changing the language from the page. Recently tons of lua example were submitted.

Re: ActiveMQ: Not ready for prime time

#50

Post by AmrMostafa »

timclark wrote: post #3
mgkimsal wrote: post #2

So, what might you recommend instead? I'm using rabbitmq on a couple of projects, and have been a bit underwhelmed by the lack of management tools that come with it. I figured something as basic as getting a list of what's in a queue and being able to then remove that item from a queue would not require me to write custom code, but I seem to have been wrong.

I believe the RabbitMQ management plugin is what you need, provides HTML user interface and HTML API. The BQL plugin, which is now sadly unsupported by the Rabbits, used to be a nice command line interface, it is a shame it is no longer supported.

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, small & clean code base, small footprint, simple, active (more features are always being added).

What I don't like about RabbitMQ? While it's FLOSS inside out, its development isn't exactly a "community" work. For example, I can't report an issue, attach a patch, and receive a reviewer/committer feedback about it and possibly get it in. In fact, I can't even report an issue into their issue tracking system -- I just have the mailing list. That said, I believe they said they are going to fix that part "soon".

Post reply on HN