4 ms·

Surprised you're using RabbitMQ. It's one of those things which work great until they don't (clustering is particularly bad), and then you have almost zero insi

Surprised you're using RabbitMQ. It's one of those things which work great until they don't (clustering is particularly bad), and then you have almost zero insight into the issue, and have to resort to the Pivotal mailing list. Have you looked at NATS at all? We're using it as a message bus for one app and it's been fantastic. It is, however, an in-memory queue, and the current version cannot replace Rabbit for queues that require durability.

fernandotakai 10y ago
i've been using rabbitmq heavily (as in, the whole infrastructure is based on two rabbitmq servers) for a long time and i've never seen it fail. tbh, i never used clustering (because it's one of the shittiest clustering implementations i've ever seen) but we do use two servers (publishers connect to one randomly and consumers connect to both) and it seems to handle millions of messages without any issues. of all servers i've ever used, rabbitmq is by far the most stable (together with ejabberd).
- lobster_johnson 10y ago
  RabbitMQ is decent if you don't use clustering (which, I agree, is shitty). I have some quibbles with the non-clustered parts, but nothing big. Right now, the main annoyance is that it's impossible, as far as I understand, to limit its memory usage. You can set a "VM high watermark" and some other things, but beyond that, it will — much like, say, Elasticsearch — use a large amount of mysterious memory that you have no control over. You can't just say "use 1GB and nothing more", which is problematic on Kubernetes where you want to pack things a bit tightly. This happens even if all the queues are marked as durable.
  - fernandotakai 10y ago
    yeah we have dedicated machines to rabbitmq because it's basically memory hungry. but i like it that way because it's only going to crash if the machine crashes.
d23 10y ago
Hmm, I'll take a look at that. For websockets, non-durability seems like a fine tradeoff, so it sounds interesting. Thanks!
- lobster_johnson 10y ago
  Note that NATS is currently pub/sub, which is a "if a tree falls in the forest" situation. Messages don't go anywhere if nobody is subscribing. So it's awesome for realtime firehose-type use cases where a websocket client connects, receives messages (every client gets all the messages, although NATS also supports load-balanced fanout) for a while, then eventually disconnects. NATS is ridiculously fast [1], too. There's an add-on currently in beta, NATS Streaming [1], which [2] has durability, acking/redelivery and replay, so covers most of what you get from both RabbitMQ and Kafka. It looks very promising. [1] http://bravenewgeek.com/tag/nats/ http://bravenewgeek.com/tag/nats/ [2] https://nats.io/documentation/streaming/nats-streaming-intro/ https://nats.io/documentation/streaming/nats-streaming-intro...
manigandham 10y ago
NATS is only a pub/sub system. NATS Streaming uses an embedded NATS server while building queuing and persistence on top. It works well.
- lobster_johnson 10y ago
  https://news.ycombinator.com/item?id=14111856 https://news.ycombinator.com/item?id=14111856

fernandotakai 10y ago

i've been using rabbitmq heavily (as in, the whole infrastructure is based on two rabbitmq servers) for a long time and i've never seen it fail. tbh, i never used clustering (because it's one of the shittiest clustering implementations i've ever seen) but we do use two servers (publishers connect to one randomly and consumers connect to both) and it seems to handle millions of messages without any issues. of all servers i've ever used, rabbitmq is by far the most stable (together with ejabberd).

lobster_johnson 10y ago
RabbitMQ is decent if you don't use clustering (which, I agree, is shitty). I have some quibbles with the non-clustered parts, but nothing big. Right now, the main annoyance is that it's impossible, as far as I understand, to limit its memory usage. You can set a "VM high watermark" and some other things, but beyond that, it will — much like, say, Elasticsearch — use a large amount of mysterious memory that you have no control over. You can't just say "use 1GB and nothing more", which is problematic on Kubernetes where you want to pack things a bit tightly. This happens even if all the queues are marked as durable.
- fernandotakai 10y ago
  yeah we have dedicated machines to rabbitmq because it's basically memory hungry. but i like it that way because it's only going to crash if the machine crashes.

d23 10y ago

Hmm, I'll take a look at that. For websockets, non-durability seems like a fine tradeoff, so it sounds interesting. Thanks!

lobster_johnson 10y ago
Note that NATS is currently pub/sub, which is a "if a tree falls in the forest" situation. Messages don't go anywhere if nobody is subscribing. So it's awesome for realtime firehose-type use cases where a websocket client connects, receives messages (every client gets all the messages, although NATS also supports load-balanced fanout) for a while, then eventually disconnects. NATS is ridiculously fast [1], too. There's an add-on currently in beta, NATS Streaming [1], which [2] has durability, acking/redelivery and replay, so covers most of what you get from both RabbitMQ and Kafka. It looks very promising. [1] http://bravenewgeek.com/tag/nats/ http://bravenewgeek.com/tag/nats/ [2] https://nats.io/documentation/streaming/nats-streaming-intro/ https://nats.io/documentation/streaming/nats-streaming-intro...

manigandham 10y ago

NATS is only a pub/sub system. NATS Streaming uses an embedded NATS server while building queuing and persistence on top. It works well.

lobster_johnson 10y ago
https://news.ycombinator.com/item?id=14111856 https://news.ycombinator.com/item?id=14111856