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

71–80 of 93 posts

Re: ActiveMQ: Not ready for prime time

#71

Post by rbranson »

Uchikoma wrote: post #67
rbranson wrote: post #46

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

The Reddit guys think differently: "[...] (rabbitmq) died, which added about an hour to the downtime. It dies like this pretty often at 2am or at other especially bad times. Usually it doesn't cause any data-loss, just sleep-loss (its queues are persisted and the apps just build up their own queues until it comes back up), but in this case it decided to crash in a way that corrupted its database of persisted queues b…

"Crashed"... I'm glad they're using such specific terms. I give them a lot of slack because they run that shop with a skeleton crew, but they sure do run into a lot of issues with perfectly good software, have Twitter levels of performance & availability, and make some very odd technical decisions.

Re: ActiveMQ: Not ready for prime time

#72

Post by rbranson »

anttipoi wrote: post #69

I've now been involved in two projects where I would have needed a queue with following characteristics: - simple pub-sub, queue-like: m producers, n consumers - decent performance (order of hundreds of requests per second) - high availability for message persistence (I don't want to loose messages) - no strict FIFO needed, just some kind of lesser fairness (newer items should not block older ones from passing throug…

RabbitMQ itself doesn't have HA built-in, but warm spare HA is rather simple and well-documented, built on-top of Pacemaker and DRBD. It works quite well.

Re: ActiveMQ: Not ready for prime time

#73

Post by rabbitmq »

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.

Tim, what do you think is cool about BQL that might be needed in the future?

Re: ActiveMQ: Not ready for prime time

#74

Post by rabbitmq »

AmrMostafa wrote: post #50
timclark wrote: post #3

Earlier quoted context omitted.

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, 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 pain in the butt.

Re: ActiveMQ: Not ready for prime time

#75

Post by rabbitmq »

Uchikoma wrote: post #67
rbranson wrote: post #46

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

The Reddit guys think differently: "[...] (rabbitmq) died, which added about an hour to the downtime. It dies like this pretty often at 2am or at other especially bad times. Usually it doesn't cause any data-loss, just sleep-loss (its queues are persisted and the apps just build up their own queues until it comes back up), but in this case it decided to crash in a way that corrupted its database of persisted queues b…

So For The Record.

Reddit are atill using RabbitMQ and as far as I can tell they are happy with it.

If anyone has any doubts or questions about this, please email us. info@rabbitmq.com

Re: ActiveMQ: Not ready for prime time

#76

Post by rabbitmq »

rbranson wrote: post #72
anttipoi wrote: post #69

I've now been involved in two projects where I would have needed a queue with following characteristics: - simple pub-sub, queue-like: m producers, n consumers - decent performance (order of hundreds of requests per second) - high availability for message persistence (I don't want to loose messages) - no strict FIFO needed, just some kind of lesser fairness (newer items should not block older ones from passing throug…

RabbitMQ itself doesn't have HA built-in, but warm spare HA is rather simple and well-documented, built on-top of Pacemaker and DRBD. It works quite well.

Thank-you.

The docs for HA are here: http://www.rabbitmq.com/pacemaker.html

This also works with Veritas if you use that instead of DRDB.

Please note that we are currently QAing a new HA model which is active/active. Watch this space!

Re: ActiveMQ: Not ready for prime time

#77

Post by rajdavies »

kitplummer wrote: post #21

Yikes. If you're smart, you'll do your diligence and not rely on one person's experience with ActiveMQ. Remember, it is an Apache project - so if something aint there, feel free to fill it in (re: documentation). I can't believe the ActiveMQ/FuseSource guys weren't willing to work it out with David either. Perhaps there's a bit of open source/commercial software wrangling behind this story. Won't be the first/last ti…

I'm not sure who David Pollak talked to at FuseSource - nobody on the ActiveMQ team there know him - and the execs are scratching their heads too.

Re: ActiveMQ: Not ready for prime time

#78

Post by rabbitmq »

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…

"a feature of the open source Erlang VM that's improved in the pay-for-support version"

Erlang was created by a telco in the 1990s and since then has been battered in production by serious users. It's real software. The version that Ericsson provide as open source is not crippleware as you seem to imply.

"RabbitMQ pays the performance cost of bouncing everything off the disk"

No it doesn't.

RabbitMQ only uses the disk if tell it to do so, eg if you require messages to be persisted when they cannot be delivered immediately.

"memory usage can grow and grow"

If you stuff data into a messaging server without draining it on the consumer side, then memory usage will grow. This will also happen if you write your messaging system in C++.

There are two solutions to this problem: - flow control, where you tell producers to back off - paging to disk, where you flush data from memory when it is on the disk

Neither of these is trivial to implement which is why there is a big gap between toy messaging systems and serious products.

As others point out on this page, RabbitMQ has support for both these features. In particular a lot of memory management capability has been added since 2.0.

I hope this helps.

Re: ActiveMQ: Not ready for prime time

#79

Post by rajdavies »

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…

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.

Re: ActiveMQ: Not ready for prime time

#80

Post by rabbitmq »

wslh wrote: post #61

There is a lot of buzz about open source queue systems. I have tried for example the RabbitMQ with very bad results. I'll rather explain... one interesting concept about queues is contention and this is where RabbitMQ and others are behind. The strange thing is that contention is an old concept from the old mainframes. For example the last time I checked you can't block a produced in RabbitMQ based on the number of m…

If you have any questions or problems involving RabbitMQ please email us (info@rabbitmq.com) or post to the mailing list.

"one interesting concept about queues is contention and this is where RabbitMQ and others are behind"

Can you explain what this means? What kind of contention are you talking about. You say "RabbitMQ and others" - which others? Who implements this feature and what does it look like?

"you can't block a produced in RabbitMQ based on the number of messages on the queue"

Yes you can.

Well - it depends on your use case. RabbitMQ enables you to determine queue length, and supports flow control.

But, perhaps you had something else in mind?

Post reply on HN