| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Rabbit fifo snapshotting improvements
|
| | | |
|
| | |\
| |/
|/| |
|
| |\ \
| | |
| | | |
Dead letter testing
|
| | |\ \
| |/ /
|/| |
| | |
| | | |
Conflicts:
src/rabbit_quorum_queue.erl
|
| |\ \ \
| | | |
| | | | |
Feature flags support + make #amqqueue{} private
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This fixes a warning about `erlang:get_stacktrace()` deprecation by
Erlang 21 compiler.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The message is also sent from `rabbit_amqqueue_process` and
`rabbit_mirror_queue_slave` to avoid a leak of mandatory references in
3.7.x channels. For 3.8.x channels, this will be a no-op.
This is just to make the node compatible with a 3.7.x cluster. This
message is unused in 3.8.x and marked as deprecated.
[#163222515,#159298729]
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is just to make the node compatible with a 3.7.x cluster. All
involved functions are marked as deprecated.
[#159298729]
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The feature flag is called `implicit_default_bindings`. It has the same
role as the previously existing upgrade function. The upgrade function
is removed in the process.
Compared to the upgrade function however, it does remove entries in the
`rabbit_route`, `rabbit_reverse_route` and `rabbit_semi_durable_route`
tables in addition to `rabbit_durable_route` table. Also, the list of
queues is taken from the `rabbit_queue` table instead of the
`rabbit_durable_queue` one.
[#163224049,#159298729]
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In a few places, the migration of the `rabbit_queue` and
`rabbit_durable_queue` Mnesia tables might conflict with accesses to
those tables.
[#159298729]
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The #amqqueue{} record is now isolated in the `amqqueue` module: all
accesses and modifications to the record are made through this helper.
The type `rabbit_types:amqqueue()` is now `amqqueue:amqqueue()`.
`amqqueue` knows about the new #amqqueue{} record introduced with quorum
queues. If the actual record is the old one (as defined in RabbitMQ
3.7.x), it calls `amqqueue_v1` which knows about the old definition.
When it needs to produce an #amqqueue{} record, it verifies if it is
allowed to, using the new Feature flags subsystem and the `quorum_queue`
feature flag specifically, and proceeds. If an old format #amqqueue{} is
required, the creation is deferred to `amqqueue_v1`.
The new modules come with a couple headers: they provide macros to
replace pattern matching with `when` conditions. The `amqqueue_v*.hrl`
headers are generated using the `macros()` functions in `amqqueue` and
`amqqueue_v1` modules.
Some operations now depend on the state of the `quorum_queue` feature
flag. In particular, creating a quorum queue is denied if the feature
flag is disabled.
In the process, the following modules were moved from rabbitmq-common to
rabbitmq-server:
* rabbit_backing_queue
* rabbit_queue_master_locator
Likewise, the few functions were copied from `rabbit_misc` to
`rabbit_amqqueue` because they depend on `amqqueue`. They don't really
need to live in rabbitmq-common and they prevent further progress with
the feature flags: feature flags need informations about the cluster.
The `quorum_queue` feature flag comes with a migration function which is
responsible of converting the #amqqueue{} records in Mnesia tables
`rabbit_queue` and `rabbit_durable_queue`. Therefore, the upgrade
function which did this is removed in this commit.
[#159298729]
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
compatibility
That new function has the behavior that `version_minor_equivalent()` had
before: it considers 3.7.x and 3.8.x as incompatible. This is useful for
plugins because the feature flags subsystem only applies to inter-node
compatibility, not plugins.
Therefore a plugin marked as compatible with 3.7.x should not be
considered as compatible with 3.8.x.
[#159298729]
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The goal is that each breaking change is implemented in way that a
RabbitMQ node having that change can work in the same cluster as other
nodes which do not know about it.
The feature flags are here to indicate which breaking changes are
"available" (i.e. the node knows about the breaking changes, but it
still runs in a backward-compatible mode) and which ones are currently
activated (i.e. the node uses the new code and older node can not be
part of the cluster anymore).
Enabling a feature flag (i.e. activating a breaking change) is a manual
operation where the user validates that the cluster is ready to switch
to the new world after the breaking change. Therefore the subsystem
ensures RabbitMQ nodes can talk to each other even if they don't have
the same code as long as they agree on using the common subset, and
prevents RabbitMQ nodes from talking to each other once the new code is
being used and one node does not understand it.
The consequence is that if a breaking change is implemented using this
new subsystem, a cluster can be upgraded one node at a time instead of
shutting down the entire cluster to upgrade.
Of course, the ability to implement a breaking change in such a way
entirely depends on the nature of that change. This new subsystem does
not guarantee that a cluster shutdown will never be required again.
[#159298729]
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
As specified for RMQ ttl
|
| |/ /
| |
| |
| |
| | |
All queue types must exhibit the same behaviour, apart from
non implemented features in quorum queues
|
| |\ \
| | |
| | | |
Configure Ra to log using lager
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Disable large heap sysmon messages
|
| |/ / /
| | |
| | |
| | | |
I like large heaps and I can not lie.
|
| | |/
| |
| |
| |
| |
| |
| | |
More regularly. Previously if more than one message was settled at a
time, stored potential snapshots could have been missed.
[#163631659]
|
| | | |
|
| |/
|
|
| |
[#163518117]
|
| |\
| |
| | |
Fix basic get message ready count
|
| | |
| |
| |
| |
| |
| |
| | |
Ensure the messages is ready is returned from basic get. Also fix
message count when using basic.delete.
[#162502929]
|
| |\ \
| | |
| | | |
Remove code that sets syslog listen IP
|
| |/ /
| |
| |
| | |
Fixes #1850
|
| |\ \
| | |
| | | |
Introduce a function that awaits startup with a timeout
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Pair: @gerhard.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Per #1848 review.
Pair @gerhard.
|
| | | |
| | |
| | | |
BOOT_STATUS_SAMPLING_INTERVAL is in ms
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Which supports a timeout.
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
rabbitmq/rabbitmq-server-1838-active-field-for-consumers
Update active flag for consumers
|
| | |\ \
| |/ /
|/| |
| | |
| | | |
Conflicts:
src/rabbit_fifo.erl
|
| |\ \ \
| |_|/
|/| | |
Queue length limit by byte size and number of messages (Drop head only)
|
