[Why]
The `feature_flags` file is used to record the states of feature flags.
The content is a formatted sorted Erlang list.
This works just fine, but reading it for a human (a developer) is more
difficult than if we had a single feature name per line. It is also more
difficult to use diff(1) on the file.
This patch ensures that the Erlang list is formatted with an item per
text line.
[How]
The format string enforces an line width of 1 column. The terms are not
truncated obviously, but the lines are wrapped immediately after an
item.
This osiris release contains optimisations and bug fixes:
* Various index scanning operations have been substantially improved
resulting in up to 10x improvement for certain cases.
* A bug which meant stream replication listener would fail if the
TLS version was limited to `tlsv1.3` has been fixed.
* A bug where the log may be incorrectly truncated when filters are
used has been fixed.
* Startup handles one more case where a file has been corrupted after
an unclean shutdown.
Providing a pre-hashed and salted password is
not significantly more secure but satisfies those
who cannot pass clear text passwords on the command
line for regulatory reasons.
Note that the optimal way of seeding users is still
definition import on node boot, not scripting with
CLI tools.
Closes#9166
when nodes are already disconnected, thus preventing
application controller timeouts and node monitor terminations,
which in some cases fails to receover completely.
When the Web-MQTT connection terminates early because of no supported
subprotocol, `terminate/3` called fhc release although no fhc obtain was
called yet. This was the case even when `use_file_handle_cache` was false,
because `#state.should_use_fhc` was not initialized.
Fixing this avoids the below harmless warning
```
[debug] error updating ets counter <0.1224.0> in table #Ref<0.2797411137.1366163457.189876>:
[{ets, update_counter,
[#Ref<0.2797411137.1366163457.189876>,
<0.1224.0>, {5, -1}],
...
[warning] FHC: failed to update counter 'obtained_socket', client pid: <0.1224.0>
```
Currently these are not allowed for use with stream queues
which is a bit too strict. Some client impl will automatically
nack or reject messages that are pending when an application
requests to stop consuming. Treating all message outcomes the same
makes as much sense as not to.
Because both `add_member` and `grow` default to Membership status `promotable`,
new members will have to catch up before they are considered cluster members.
This can be overridden with either `voter` or (permanent `non_voter` statuses.
The latter one is useless without additional tooling so kept undocumented.
- non-voters do not affect quorum size for election purposes
- `observer_cli` reports their status with lowercase 'f'
- `rabbitmq-queues check_if_node_is_quorum_critical` takes voter status into
account
Currently these are not allowed for use with stream queues
which is a bit too strict. Some client impl will automatically
nack or reject messages that are pending when an application
requests to stop consuming. Treating all message outcomes the same
makes as much sense as not to.
Because both `add_member` and `grow` default to Membership status `promotable`,
new members will have to catch up before they are considered cluster members.
This can be overridden with either `voter` or (permanent `non_voter` statuses.
The latter one is useless without additional tooling so kept undocumented.
- non-voters do not affect quorum size for election purposes
- `observer_cli` reports their status with lowercase 'f'
- `rabbitmq-queues check_if_node_is_quorum_critical` takes voter status into
account
A previous PR removed backing_queue_status as it is mostly unused,
but classic queue version is still useful. This PR returns version
as a top-level key in queue objects.
Michael Klishin
Jean-Sébastien Pédron
Karl Nilsson
GitHub
Arnaud Cogoluègnes
Ayanda Dube
Péter Gömöri
Alex Valiushko
David Ansari
Simon Unge
Diana Parra Corbacho