a5f4317c3f
Prior to this commit the follwing test was flaky:
```
bazel test //deps/rabbitmq_mqtt:v5_SUITE -t- --test_sharding_strategy=disabled \
--test_env FOCUS="-group [mqtt,cluster_size_3] -case session_takeover_v3_v5" \
--test_env RABBITMQ_METADATA_STORE=khepri --config=rbe-26 --runs_per_test=20
```
because rabbit_misc:maps_any/2 filtered out a destination queue after routing if
that destination queue wasn't associated with any matched binding key.
This commit makes the test green.
However, the root cause of this issue isn't solved:
MQTT 5.0 requires the topic exchange to return matched binding keys for
destination queues such that feature NoLocal, and Subscription
Identifiers work correctly.
The current MQTT plugin relies on session state to be stored
consistently in the database. When a new client connects, the session
state is retrieved from the database and appropriate actions are taken:
e.g. consume from a queue, modify binding arguments, etc.
With Mnesia this consistency was guaranteed thanks to sync transactions
when updating queues and bindings.
Khepri has only eventual consistency semantics. This is problematic for the
MQTT plugin in the session_takeover_v3_v5 test scenario:
1. Client subscribes on node 1 (with v3). Node 1 returns subscription
success to client.
2. **Thereafter**, another client with the same MQTT client ID connects
to node 0 (with v5). "Proper" session takeover should take place.
However due to eventual consistency, the subscription / binding isn't
present yet on node 0. Therefore the session upgrade from v3 to v5
does not take place and leads to binding keys being absent when
messages are routed to the session's queue.
|
||
|---|---|---|
| .github | ||
| bazel | ||
| deps | ||
| doc | ||
| mk | ||
| packaging | ||
| release-notes | ||
| scripts | ||
| tools | ||
| .bazelignore | ||
| .bazelrc | ||
| .bazelversion | ||
| .dockerignore | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| BAZEL.md | ||
| BUILD.bats | ||
| BUILD.bazel | ||
| BUILD.package_generic_unix | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| LICENSE-APACHE2 | ||
| LICENSE-MPL-RabbitMQ | ||
| MODULE.bazel | ||
| Makefile | ||
| PKG_LINUX.md | ||
| PKG_WINDOWS.md | ||
| README.md | ||
| SERVER_RELEASES.md | ||
| WORKSPACE | ||
| dist.bzl | ||
| erlang.mk | ||
| erlang_ls.config | ||
| moduleindex.yaml | ||
| plugins.mk | ||
| rabbitmq-components.mk | ||
| rabbitmq.bzl | ||
| rabbitmq_home.bzl | ||
| rabbitmq_package_generic_unix.bzl | ||
| rabbitmq_run.bzl | ||
| rabbitmqctl.bzl | ||
| rebar.config | ||
| user-template.bazelrc | ||
README.md
RabbitMQ Server
RabbitMQ is a feature rich, multi-protocol messaging and streaming broker. It supports:
- AMQP 0-9-1
- AMQP 1.0
- RabbitMQ Stream Protocol
- MQTT 3.1, 3.1.1, and 5.0
- STOMP 1.0 through 1.2
Installation
- Installation guides for various platforms
- Kubernetes Cluster Operator
- Changelog
- Releases on GitHub
- Currently supported released series
- Supported Erlang versions
Tutorials and Documentation
Some key doc guides include
- CLI tools guide
- Clustering and Cluster Formation guides
- Configuration guide
- Client libraries and tools
- Monitoring and Prometheus/Grafana guides
- 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
- Runnable tutorials
RabbitMQ documentation is also developed on GitHub.
Commercial Features and Support
- Commercial edition of RabbitMQ
- Commercial edition for Kubernetes
- Commercial support from VMware for open source RabbitMQ
Getting Help from the Community
- 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 on the mailing list.
Licensing
RabbitMQ server is licensed under the MPL 2.0.
Building From Source and Packaging
Copyright
(c) 2007-2023 VMware, Inc. or its affiliates.