[debacle]

As far as message queues go, I'd be hard pressed to choose anything but rabbitmq.

Easy to install, sane config out of the box, developer friendly definition, relatively flat learning curve with highly googleable answers, and widespread support for AMQP.

There may be something faster/leaner or with some bells and whistles, but if you just need message queuing it's hard to beat.

[worldsayshi]

I find rabbitmq easy-ish to use but I've been a bit surprised by the seeming lack of tools to support its use. For example, I have not been able to find an off the shelf solution for getting an overview visualization of the message flow. There are a few projects on github but they look like weekend experiments. Nothing that looks maintained.

[lsowen]

The management plugin [1] might be useful? It allows browsing of queues and clients, and includes statics and graphs for message throughput, etc

1. https://www.rabbitmq.com/management.html

[worldsayshi]

Yes it is very useful. Although it's a bit limited for getting an zoomed out view. It would be nice to have a flow chart.

Perhaps I'm colored by playing Factorio like games. It feels like managing a message queue is quite similar to managing an abstract factory line. Would be nice if I could have a similar visualization.

[perlgeek]

RabbitMQ as a stand-alone server is awesome.

Getting RabbitMQ to work in a cluster is a nightmare.

Be aware of that when selecting it as your message queue :-)

[the_doctah]

Why would rabbitMQ standalone be any different than running it as part of a cluster? You only ever need 1 instance of it.

If your exchanges, queues, routing keys, etc. are planned out ahead of time it should not be difficult to manage.

[perlgeek]

Disclaimers: our attempts to run a RabbitMQ cluster were a few years back, maybe things changed since then.

First of all, operating a cluster is a hassle, sometimes (for no apparent reason) on of the members gets thrown out and doesn't automatically rejoin, you have to do that manually.

Second, and this is a bigger issue: If you use a query/response pattern, the requester typically creates a temporary queue for responses, with names generated by RabbitMQ. Those response queues are only readable for the connection that created them, so even if you were to replicate those queues and messages through the cluster, that wouldn't help anybody. BUT, the service sending the response needs to know on which cluster node the response queue, and use the connection to the right node to send the answer.

(At least this is my understanding; we had an application running on a single rabbitmq node, and when trying it on a cluster, clients wouldn't get responses; maybe the reason was something else, but the fact stands that it simply didn't work).

Such response queues are also not durable, they don't survive the failure of a node.

I assume it's possible to make applications work reliably with a RabbitMQ cluster, but I guess that would need to one of the stated goals upfront. Our attempts to retrofit applications to a cluster failed.

[nvarsj]

I think Redis Pub/Sub is up there too. Plus you get an amazing KV store.