diff options
| author | Jean-Sébastien Pédron <jean-sebastien@rabbitmq.com> | 2019-10-11 15:14:04 +0200 |
|---|---|---|
| committer | Jean-Sébastien Pédron <jean-sebastien@rabbitmq.com> | 2019-10-11 15:20:04 +0200 |
| commit | a7f3dce5b366d88b8f09470b2a897298c00aeeeb (patch) | |
| tree | 815f0a3dc7b1bfd145877e071d89e3a7948a2f69 /src/lqueue.erl | |
| parent | 152219052fd47a85c8bb4ab6e706915a31f72364 (diff) | |
| download | rabbitmq-server-git-a7f3dce5b366d88b8f09470b2a897298c00aeeeb.tar.gz | |
rabbit_feature_flags: Prevent load of the module on pre-feature-flags nodes
In a cluster, if e.g. RabbitMQ 3.7.17 packages are deployed on all
cluster member, but the nodes are not restarted yet, the first node to
restart will fail. This might happen if the timing is unfortunate during
a parallel upgrade of a cluster: nodes A and B files were updated, and
node A finishes to restart while node B is still between the files
update and the post-install script.
The reason is that the `rabbit_feature_flags` module is available on all
nodes after the package deployment. However, the module may be loaded in
a pre-feature-flags already running node. In this unexpected context,
the module fails to respond properly to the queries of the remote
restarting node.
To fix this, we use an `on_load()` hook to prevent this module from being
loaded by the Erlang code server if the context is unexpected. This will
cause the query to abort with an undefined function call, exactly like
if the module was really missing.
Outside of a running RabbitMQ instance, the load of the module is
permitted. This is useful in the case of running EUnit tests for
instance (even though this specific module doesn't have any).
The previous patch was an early version to verify the hypothesis only.
Fixes #2132.
[#169086629]
Diffstat (limited to 'src/lqueue.erl')
0 files changed, 0 insertions, 0 deletions
