build(deps): bump org.springframework.boot:spring-boot-starter-parent from 3.3.0 to 3.3.1 in /deps/rabbitmq_auth_backend_http/examples/rabbitmq_auth_backend_spring_boot_kotlin
build(deps): bump org.springframework.boot:spring-boot-starter-parent from 3.3.0 to 3.3.1 in /deps/rabbitmq_auth_backend_http/examples/rabbitmq_auth_backend_spring_boot
This reverts commit 8749c605f5.
[Why]
The patch was supposed to solve an issue that we didn't understand and
that was likely a network/DNS problem outside of RabbitMQ. We know it
didn't solve that issue because it was reported again 6 months after the
initial pull request (#8411).
What we are sure however is that it increased the testing of RabbitMQ
significantly because the code loops for 10+ minutes if the remote node
is not running.
The retry in the Feature flags subsystem was not the right place either.
The `noconnection` error is visible there because it runs earlier during
RabbitMQ startup. But retrying there won't solve a network issue
magically.
There are two ways to create a cluster:
1. peer discovery and this subsystem takes care of retries if necessary
and appropriate
2. manually using the CLI, in which case the user is responsible for
starting RabbitMQ nodes and clustering them
Let's revert it until the root cause is really understood.
Running "make -C deps/rabbit ct-feature_flags_v2" on a clean
repository would not work due to a circular dependency. Since
the plugin in question is a no-op in 4.x, only used in tests,
we make the plugin depend on nothing to avoid the issue.
* MQTT: speed up shared_SUITE:many_qos1_messages
* speed up block_only_publisher
* MQTT: reorganise tests groups
To avoid starting a new broker for each protocol group (v3,v4,v5).
Instead we run all protocol groups under a single cluster configuration
group.
* MQTT: speed up publish_to_all_queue_types_qos* tests.
* Remove separate mnesia_store group
to speed up the test suite
* Fix wrong_shard_count
* Remove unused field
* Run subset of v3 tests
The code being tested under v3 and v4 is almost identical.
To save time in CI, we therefore run only a very small subset of tests in v3.
This cuts the total time reported by CT for the shared_SUITE from 898
seconds to 614 seconds.
Also, the java_SUITE tests in v3.
* Fix wrong_shard_count
* Fix mixed version failure
---------
Co-authored-by: David Ansari <david.ansari@gmx.de>
Both FULL and MAKEFLAGS env variables need to be unset
as FULL=1 is present in both. This is a bit of a band-aid,
it's possible that other variables get propagated that
shouldn't be, but we'll fix them when they are detected.
It's technically a build target, so we didn't need to create a whole
new test rule, but it's marked as "manual" so that it doesn't cause
bazel build //... to fail
This release includes a new machine API `snapshot_installed/2`. This new
API will only be used indirectly through khepri.
This release also includes an performance improvement that reduces the chances
of building a large WAL mailbox backlog when a node is low on scheduling
resources and commands are committed by followers completing writes to disk
before the leader.
There is also a fix for a potential election deadlock.