[No details provided] RabbitMQ stops working

[car1ot]

Hello. I got an issue.

After a day of uptime, rabbitmq stopped working correctly with direct messages. On client I get an error "Timeout exceeded to send message 10 seconds". After reloading erlang and rabbitmq, all works properly. Maybe there are no garbage collector? I edited config to collect garbage in rabbitmq, read a lot of issues about it, but nothing helped.

This issue happens on all rabbitmq versions.
What to do with this issue?
Maybe you can recommend some steps to debug it?

[kjnilsson]

I suggest you inspect the management UI to see what is going on and in addition you can inspect the server log files for anything unusual.

I understand you are not keen on sharing any details with us which is fine but if you change your mind we may be able to help if you provide:

1. Reproduction steps, ideally with a minimal client application(s)
2. Server logs
3. Management UI screenshots of anything that looks relevant.
4. The output of the rabbitmq-diagnostics report
5. And yes, RabbitMQ version is essential information to go any further.

[michaelklishin]

Dont ask me about versions because this issue happens on all rabbitmq versions

Sorry but if you are not willing to provide the information we ask for, we'd have to ask you to take your questions elsewhere. You pay $0 for asking the core team questions, so at least show a little bit of respect to our time and cooperate.

Nodes can stop for many reasons. If we assume that it had something to do with the amount of memory used then collecting metrics related memory use and or at least taking a look at breakdown when the node reaches this state is essential.

Quorum queues in modern RabbitMQ versions keep
messages in memory for a very short time. So do streams.
With older versions it was a matter of configuration.

Classic queues with v1 storage would keep a substantial amount of messages in memory and move
them to disk only when the node consumes 50% of its configured high watermark. In addition, applications can instruct RabbitMQ to keep messages in memory via a message property called delivery mode. In modern versions this only has any effect on
classic queues v1, so, classic queues by default.

Some other common causes for high or growing memory footprint of a node are

• Resource leaks by applications, in particular channel leaks or connection leaks
• A large number of concurrent client connections: this can be addressed via configuration
• Due to memory fragmentation. This can also be remedied with some advanced configuration.

So as you can see, the effects of garbage collection on queues is not a significant factor in most cases, although it can be.

With this information you should be able to narrow down what scenarios may or may not be relevant
to your case, and what queue types (or streams) have lower memory footprint.

[michaelklishin]

So I should plan to change rabbitmq to something else, like Kafka if you will not resolve the issue.

@car1ot go ahead and change to whatever you want. This kind of abusive language towards open source software maintainers is not OK. You get the software for free, you get support for free, and you are not even willing to provide relevant information and treat the maintainers with decency.

[erlmachinedev]

So I should plan to change rabbitmq to something else, like Kafka if you will not resolve the issue.

Sorry bro, keep at as a joke but it could be the same like:

So I should plan to change bicycle 🚴 to something else, like a skateboard 🛹 if you will not resolve the issue.

There are completely different platforms with different meanings (the only common thing between them is a data transfer from the source to destination point)

After reloading erlang

I guess it's important to specify whether you are working in shell with RabbitMQ compiled and run from a source code or not.
I am not a maintainer but I guess this point is to be specified (otherwise it's not clear what does "reloading Erlang" mean).

Maybe there are no garbage collector?

It's in place https://www.erlang.org/doc/apps/erts/garbagecollection (it's one of the advantages of Erlang VM)

[michaelklishin]

Pretty sure he/she tries to communicate that the nodes are OOM-killed or something like that.
So, it has nothing to do with runtime GC. At least that's what I'd based my above response (the longer one).