It was expensive to delete files because we had clean up the index and to get the messages in the file we have to scan it. Instead of cleaning up the index on file delete this commit deletes from the index as soon as possible. There are two scenarios: messages that are removed from the current write file, and messages that are removed from other files. In the latter case, we can just delete the index entry on remove. For messages in the current write file, we want to keep the entry in case fanout is used, because we don't want to write the fanout message multiple times if we can avoid it. So we keep track of removes in the current write file and do a cleanup of these entries on file roll over. Compared to the previous implementation we will no longer increase the ref_count of messages that are not in the current write file, meaning we may do more writes in fanout scenarios. But at the same time the file delete operation is much cheaper. Additionally, we prioritise delete calls in rabbit_msg_store_gc. Without that change, if the compaction was lagging behind, we could have file deletion requests queued behind many compaction requests, leading to many unnecessary compactions of files that could already be deleted. |
||
---|---|---|
.github | ||
deps | ||
doc | ||
mk | ||
packaging | ||
release-notes | ||
scripts | ||
selenium | ||
.dockerignore | ||
.elp.toml | ||
.git-blame-ignore-revs | ||
.gitignore | ||
.mailmap | ||
CODE_OF_CONDUCT.md | ||
COMMUNITY_SUPPORT.md | ||
CONTRIBUTING.md | ||
LICENSE | ||
LICENSE-APACHE2 | ||
LICENSE-MPL-RabbitMQ | ||
Makefile | ||
PKG_LINUX.md | ||
PKG_WINDOWS.md | ||
README.md | ||
SERVER_RELEASES.md | ||
erlang.mk | ||
erlang_ls.config | ||
plugins.mk | ||
rabbitmq-components.mk | ||
rebar.config |
README.md
RabbitMQ Server
RabbitMQ is a feature rich, multi-protocol messaging and streaming broker. It supports:
- AMQP 1.0
- AMQP 0-9-1
- RabbitMQ Stream Protocol
- MQTT 3.1, 3.1.1, and 5.0
- STOMP 1.0 through 1.2
- MQTT over WebSocket
- STOMP over WebSocket
- AMQP 1.0 over WebSocket (supported in VMware Tanzu RabbitMQ)
Installation
- Currently supported released series
- Installation guides for various platforms
- Kubernetes Cluster Operator
- Changelog
- Releases on GitHub
- Community Support Eligibility Policy
- Supported Erlang versions
Tutorials and Documentation
Some key doc guides include
- CLI tools guide
- Clustering and Cluster Formation
- Configuration guide
- Client libraries and tools
- Monitoring and Prometheus/Grafana
- Upgrading
- Kubernetes Cluster Operator
- Production checklist
- Quorum queues: a replicated, data safety- and consistency-oriented queue type
- Streams: a persistent and replicated append-only log with non-destructive consumer semantics
- Runtime Parameters and Policies
- Runnable tutorials
RabbitMQ documentation is also developed on GitHub.
Commercial Features and Support
- Commercial editions of RabbitMQ
- Commercial edition for Kubernetes
- Commercial support from Broadcom for open source RabbitMQ
Getting Help from the Community
Please read the Community Support Eligibility Policy document first.
The recommended community forums are
- GitHub Discussions
- Community Discord server
#rabbitmq
on Libera Chat
Contributing
See CONTRIBUTING.md and our development process overview.
Questions about contributing, internals and so on are very welcome in GitHub Discussions
or community Discord server in the core-and-plugin-dev
channel.
Licensing
RabbitMQ server is licensed under the MPL 2.0.
Community Support Eligibility Policy document explains the open source RabbitMQ support policy adopted by the RabbitMQ Core Team.
Building From Source and Packaging
Copyright
(c) 2007-2025 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.