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

RabbitMQ 4.0

github.com

Post reply on HN
Print view View original

111–120 of 120 posts

Re: RabbitMQ 4.0

#111

Post by hyperadvanced »

ehsanu1 wrote: post #20
hyperadvanced wrote: post #14

Earlier quoted context omitted.

Have used both extensively: NATS, especially in its most elementary form, is braindead simple, stateless, and ootb functional. If I only want a message broker/pubsub, I pick that. If I know on day 1 that I need queues or persistence, I would probably pick Rabbit over NATS’ offering (Jetstream).

What does Jetstream lack wrt queues/persistence?

It doesn’t lack anything in particular, it’s just heavier weight compared to Rabbit. I would start with amqp and iterate towards NATS with scale

Re: RabbitMQ 4.0

#112

Post by atombender »

hyperadvanced wrote: post #110
atombender wrote: post #42

Earlier quoted context omitted.

Not the parent, but I would. We've been using NATS for about five years at my company, and we recently adopted JetStream, and have been really impressed with it. NATS, especially with JetStream now, is a Swiss Army knife of messaging. It can do RPC, Kafka-type batch streaming, low-latency realtime notifications, large-scale network transfer, offline sync, work queues, mirroring, weighted routing, partitioning... it's…

Do you run jetstream on k8s? I’m curious if blob/kv is more reliable than redis sentinel on single node deployments. Lots of quorum issues with redis

Yes, and no issues at all. We run superclusters with a bunch of nodes, and the Raft-based leader election system has worked flawlessly so far (knock on wood!).

Keep in mind that NATS does not yet support value operations other than setting the whole value. Optimistic locking is supported, but NATS does not have inc/decrement, append, set members, etc. I believe such support is on the horizon, however.

Re: RabbitMQ 4.0

#113

Post by rhodin »

pas wrote: post #93
nurettin wrote: post #62

Earlier quoted context omitted.

The most common elephant foot gun in the room is buggy processes letting queues grow. RMQ immediately slows down (due to mnesia causing delays) and processes start dropping messages despite having system resources to grow.

can you elaborate on the details? I have some memories about running OpenStack where Rabbit "was slow", but we never figured out why. mnesia is the storage layer?

Mnesia is _not_ the storage layer for messages (except for delayed messages).

Mnesia stores vhosts, users, permissions, queue definitions and more. This is being transitioned to Khepri, which improves a lot of things (maybe most importantly netsplits) but not directly message speeds.

Re: RabbitMQ 4.0

#114

Post by sebazzz »

rhodin wrote: post #2

This release includes a new (native, no longer a plugin) AMQP 1.0 implementation, new quorum queue features, and a new schema data store (Khepri)

AMQP 1.0 is great - then you can, behind the right abstraction layer, use it as drop-in replacement for Azure Service Bus or similar.

Re: RabbitMQ 4.0

#115

Post by sebazzz »

Jenk wrote: post #19

I lost a lot of respect for the RabbitMQ maintainers when they refused to honor the semantic versioning scheme in package managers like nuget/maven/etc. "Safely upgrading" was impossible. 3.5 => 3.6 saw the removal of an argument. They didn't lose my respect for the removal of the argument, however, they lost my respect for whatabouting the conversation calling SemVer a "no true scotsman" fallacy, then trying to clai…

> I lost a lot of respect for the RabbitMQ maintainers when they refused to honor the semantic versioning scheme in package managers like nuget/maven/etc. "Safely upgrading" was impossible. 3.5 => 3.6 saw the removal of an argument.

Well, at least AMQP 1.0 is now supported so I expect that for most things you are able to use any client now.

Re: RabbitMQ 4.0

#116

Post by realcombatwomba »

packetlost wrote: post #6
leetharris wrote: post #4

Earlier quoted context omitted.

This is how I feel about NATS: https://nats.io/ It's an infinitely more friendly version of Kafka, pub/sub, etc that is extremely lightweight. Yet every environment trends towards Kafka because it was "chosen" by the big corps.

I've used both and NATS is definitely what I'd pick starting out. RabbitMQ is great too, but its heavier and harder to configure. Federation is the killer feature of RabbitMQ that NATS doesn't really have (afaik?).

NATS JetStream has equivalent functionality to federation out of the box with stream sourcing, combined with super-clustering and leaf-nodes. You can have streams that source and combine messages (with filters and subject transformation) from other sources and that sourcing happens in a 'guaranteed store and forward' manner, even if for example the stream being sourced is located in another cluster in a different region or provider or in an edge device (running a leaf node) that has only partial network connectivity (e.g. on a vehicle) and completely different security setup.

(for more detail check out this and the other YouTube videos on the Synadia channel https://youtu.be/WH55czo1BNk)

Re: RabbitMQ 4.0

#117

Post by munksbeer »

atombender wrote: post #45
shandor wrote: post #7

Earlier quoted context omitted.

So how about NATS compared to RabbitMQ? If building from scratch, what would drive a design or team towards NATS?

Two different models. The metaphor I like to use is that RabbitMQ is a postal system, while NATS is a switchboard. RabbitMQ is a "classical" message broker. It routes messages between queues. Messages are treated like little letters that fly everywhere. They're filed in different places, and consumers come by and pick them up. Core NATS isn't really a message broker, but more of a network transport. There are no queu…

I'm late replying to this comment but NATS sounds interesting. Given this comment:

>We use NATS for different use cases at my company. In one use case, clients connect to an API to follow live, low-latency change events.

Do you require any form of guaranteed delivery for these events? And what do you consider low latency?

Re: RabbitMQ 4.0

#118

Post by atombender »

munksbeer wrote: post #117
atombender wrote: post #45

Earlier quoted context omitted.

Two different models. The metaphor I like to use is that RabbitMQ is a postal system, while NATS is a switchboard. RabbitMQ is a "classical" message broker. It routes messages between queues. Messages are treated like little letters that fly everywhere. They're filed in different places, and consumers come by and pick them up. Core NATS isn't really a message broker, but more of a network transport. There are no queu…

I'm late replying to this comment but NATS sounds interesting. Given this comment: >We use NATS for different use cases at my company. In one use case, clients connect to an API to follow live, low-latency change events. Do you require any form of guaranteed delivery for these events? And what do you consider low latency?

Guaranteed delivery, yes. Latency is in the low millisecond range. Very happy with performance and stability.

Re: RabbitMQ 4.0

#119

Post by munksbeer »

atombender wrote: post #118
munksbeer wrote: post #117

Earlier quoted context omitted.

I'm late replying to this comment but NATS sounds interesting. Given this comment: >We use NATS for different use cases at my company. In one use case, clients connect to an API to follow live, low-latency change events. Do you require any form of guaranteed delivery for these events? And what do you consider low latency?

Guaranteed delivery, yes. Latency is in the low millisecond range. Very happy with performance and stability.

Thanks

Re: RabbitMQ 4.0

#120

Post by hyperadvanced »

atombender wrote: post #112
hyperadvanced wrote: post #110

Earlier quoted context omitted.

Do you run jetstream on k8s? I’m curious if blob/kv is more reliable than redis sentinel on single node deployments. Lots of quorum issues with redis

Yes, and no issues at all. We run superclusters with a bunch of nodes, and the Raft-based leader election system has worked flawlessly so far (knock on wood!). Keep in mind that NATS does not yet support value operations other than setting the whole value. Optimistic locking is supported, but NATS does not have inc/decrement, append, set members, etc. I believe such support is on the horizon, however.

Thanks for this, I’ll have a look. I use redis largely for memorization but have had a lot of issues running it within k8s for whatever reason
Post reply on HN