This configuration is not guaranteed to be safe to change after a stream has bee n
declared and thus we'll remove the ability to change it after the initial
declaration. Users should favour the x- queue arg for this config but it will still
be possible to configure it as a policy but it will only be evaluated at
declara tion time.
This means that if a policy is set for a stream that re-configures the
`stream-m ax-segment-size-bytes` key it will show in the UI as updated but
the pre-existing stream will not use the updated configuration.
The key has been removed from the UI but for backwards compatibility it is still
settable.
NB: this PR adds a new command `update_config` to the stream coordinator state
machine. Strictly speaking this should require a new machine version but we're by
passing that by relying on the feature flag instead which avoids this command
being committed before all nodes have the new code version. A new machine version
can lower the availability properties during a rolling cluster upgrade so in
this case it is preferable to avoid that given the simplicity of the change.
1. Allow to inspect an (web) MQTT connection.
2. Show MQTT client ID on connection page as part of client_properties.
3. Handle force_event_refresh (when management_plugin gets enabled
after (web) MQTT connections got created).
4. Reduce code duplication between protocol readers.
5. Display '?' instead of 'NaN' in UI for absent queue metrics.
6. Allow an (web) MQTT connection to be closed via management_plugin.
For 6. this commit takes the same approach as already done for the stream
plugin:
The stream plugin registers neither with {type, network} nor {type,
direct}.
We cannot use gen_server:call/3 anymore to close the connection
because the web MQTT connection cannot handle gen_server calls (only
casts).
Strictly speaking, this commit requires a feature flag to allow to force
closing stream connections from the management plugin during a rolling
update. However, given that this is rather an edge case, and there is a
workaround (connect to the node directly hosting the stream connection),
this commit will not introduce a new feature flag.
1. Allow to create queues without `x-queue-type` argument, which give
default queue type logic a chance to run. What's more, those queues
definitions will be exported without `x-queue-type`, so they can be
loaded into another vhost and default queue logic will be applied
again.
2. Show default queue type on the vhost page and the vhosts list pages
Deprecate queue-leader-locator values 'random' and 'least-leaders'.
Both become value 'balanced'.
From now on only queue-leader-locator values 'client-local', and
'balanced' should be set.
'balanced' will place the leader on the node with the least leaders if
there are few queues and will select a random leader if there are many
queues.
This avoid expensive least leaders calculation if there are many queues.
This change also allows us to change the implementation of 'balanced' in
the future. For example 'balanced' could place a leader on a node
depending on resource usage or available node resources.
There is no need to expose implementation details like 'random' or
'least-leaders' as configuration to users.
Prior to this commit:
1. When a new quorum queue was created, the local node + random nodes
were selected as replicas.
2. Always local node became leader.
For example, when an AMQP client connects to a single RabbitMQ node and
creates N quorum queues, all N leaders will be on that node and replicas
are not evenly distributed across the RabbitMQ cluster.
If N is small and the RabbitMQ cluster has many nodes, some nodes might
not host any quorum queue replicas at all.
After this commit:
1. When a new quorum queue is created, the local node + RabbitMQ nodes
with least quorum queue replicas are selected.
This will nicely distribute the quorum queue replicas across the
RabbitMQ cluster.
2. Support (x-)queue-leader-locator argument / policy with
* client-local (stays the default)
* random
* least-leaders
The same settings are already available for streams.
Remove quorum queue arguments and quorum queue policies
(x-)max-in-memory-length and (x-)max-in-memory-bytes
from the Management UI since they are deprecated since RabbitMQ 3.10.
They have no effect anymore since message bodies will not be stored in
memory.
The same product info is also available from the `/overview` and
`/definitions` API endpoints.
If the product info is unavailable, the API and the web UI default to
"RabbitMQ" and the underlying RabbitMQ version.
[#170341080]
Marcial Rosales
Karl Nilsson
Diana Parra Corbacho
Johan Rhodin
Michael Klishin
Marcial Rosales
Iliia Khaprov
Michal Kuratczyk
Michael Klishin
Alex Valiushko
David Ansari
Alexey Lebedeff
Loïc Hoguin
GitHubPang
Arnaud Cogoluègnes
dcorbacho
kjnilsson
Johan Rhodin
Jean-Sébastien Pédron
Diana Corbacho