Live data from Hacker News

ActiveMQ: Not ready for prime time

goodstuff.im

1–10 of 93 posts

Re: ActiveMQ: Not ready for prime time

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

Re: ActiveMQ: Not ready for prime time

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

Re: ActiveMQ: Not ready for prime time

#4
a lot of what is listed here are all standard caveats of things one needs to consider in just about any heavy enterprise-java environment.

i think you could sum this up that he simply wasn't working in a situation that warranted the division-of-labor and configuration flexibility that the product offers.

Re: ActiveMQ: Not ready for prime time

#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 basically be thought of as a black box. But that's also kind of the point.

Re: ActiveMQ: Not ready for prime time

#8

sorta reminds me of the time I built something in 2001 which was a reactive system that was sort of a web crawler but also a bit more... seems demented looking back, but I used qmail as a message queue system for it.

i've considered xmpp as a queue, and hear some do use it!

Re: ActiveMQ: Not ready for prime time

#9

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, perhaps these things are improved in newer versions. Still, the behavior of the Erlang VM itself was relevant.

As a C++ programmer, I wouldn't feel comfortable abstracting away memory management for this type of server which is both so memory intensive and requires high reliability.

But of course many people swear by highly reliable JVM based stuff, so perhaps I'm wrong about it. :-)

Re: ActiveMQ: Not ready for prime time

#10
> It's not correctly configured out of the box.

You mean there's a correct configuration? Also, Tomcat, Jetty, PostgreSQL, and Ngnix don't "install correctly" out of the box as described here. Tomcat clusters set themselves up? Postgres? Hell, I think default shared buffers allocation is 32 MB...

> Anything that streams bytes

I'm not sure what the author is trying to do. Doesn't sound like queuing to me...

The documentation is terrible, so I'll give that up. It is unfortunate that there is so much experimentation involved in setting it up. ActiveMQ is immensely versatile and configurable, and it's sort of necessarily complex to get it perfect for your task. It's not a turn-key software; it's a systems architecture component.

Post reply on HN