fe8b9df5e1
This commit adds a test case for a regression/bug that occurs in Khepri. ``` make -C deps/rabbit ct-bindings t=cluster:binding_args RABBITMQ_METADATA_STORE=mnesia ``` succeeds, but ``` make -C deps/rabbit ct-bindings t=cluster:binding_args RABBITMQ_METADATA_STORE=khepri ``` fails. The problem is that ETS table `rabbit_khepri_index_route` cannot differentiate between two bindings with different binding arguments, and therefore deletes entries too early, leading to wrong routing decisions. The solution to this bug is to include the binding arguments in the `rabbit_khepri_index_route` projection, similar to how the binding args are also included in the `rabbit_index_route` Mnesia table. This bug/regression is an edge case and exists if the source exchange type is `direct` or `fanout` and if different bindings arguments are used by client apps. Note that such binding arguments are entirely ignored when RabbitMQ performs routing decisions for the `direct` or `fanout` exchange. However, there might be client apps that use binding arguments to add some metadata to the binding, for example `app-id` or `user` or `purpose` and might use this metadata as a form of reference counting in deciding when to delete `auto-delete` exchanges or just for informational/operational purposes. |
||
|---|---|---|
| .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
#rabbitmqon 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.