| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Introduce a persistent internal cluster ID
|
| | |
| |
| |
| | |
Pair: @vanlightly
|
| |/
|
|
|
|
|
|
|
|
|
| |
That the operator cannot and are not supposed to control.
The ID is cluster-wide and stored as a global runtime parameter to make
sure it is replicated across all nodes.
It is intentionally excluded from imported definitions because it is not
meant to be reused.
This ID would be useful in several features/plugins under development.
|
| | |
|
| |\
| |
| | |
Fix bad type of result of ack function.
|
| | | |
|
| |/ |
|
| |\
| |
| | |
rabbit: Change start_apps/2 to call application:ensure_all_started/2
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
.. instead of reinventing about the same logic.
start_apps/2 is not called to start the `rabbit` application anymore (it
is started as a normal Erlang application now). It means it's only used
to start plugins which are also supposed to be regular Erlang
applications.
It runs boot steps unconditionally as well (because this function never
starts `rabbit).
One difference with the previous code is that the previous code started
all loaded applications. This seemed unnecessary and even caused issues
with testsuites where some applications were loaded like `rabbitmqctl`
but were not meant to be started.
Another difference is that before, all boot steps were executed at once,
then all plugins were started. Now, to improve consistency and make sure
that a dependency is fully ready before a plugin which depends on it
starts, for each application we execute the boot steps then start it,
before moving to the next.
[#170870798]
|
| |\
| |
| | |
rabbit: Fix plugins' run_boot_steps() vs. start order
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before `rabbit` startup code was rewritten as part of
rabbitmq/rabbitmq-server#2180 to make it closer to a regular Erlang
application, plugins' boot steps were executed before plugins were
started.
This commit restores this behavior. Indeed the initial patch inverted
them by starting the plugins first, then executed the boot steps.
It also brings another improvement in the process: a dependency has its
boot steps executed and is started before a plugin which depends on it
is considered. This should improve consistency.
Note that the `start_apps/2` function, which is run when a user enables
a plugin at runtime must be improved as well. There is a work in
progress in rabbitmq/rabbitmq-server#2219.
|
| |
|
|
|
| |
Those are all the testsuites which take more than 5 minutes in
Concourse.
|
| |\
| |
| | |
Handle timeout error on the rebalance function
|
| | |
| |
| |
| | |
Fixes: https://github.com/rabbitmq/rabbitmq-server/issues/2214
|
| |\ \
| |/
|/| |
Unsupported if_empty and if_unused flags for delete quorum queues
|
| | |
| |
| |
| | |
References #2211
|
| | |
| |
| |
| | |
[#167065717]
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Those plugins are created at runtime. We just need to populate the list
of `applications` they depend on. This list must include `rabbit`.
This will be even required once #rabbitmq/rabbitmq-server#2212 is
accepted.
|
| | |
| |
| |
| |
| |
| | |
rabbit_shovel_test is not a plugin in fact.
This reverts commit 3cf8b6384a9986e227dac3552f1b4208731ed84a.
|
| | |
| |
| |
| |
| |
| |
| | |
It should depend on `rabbit`.
This will be even required once #rabbitmq/rabbitmq-server#2212 is
accepted.
|
| |\ \
| |/
|/| |
rabbit_plugins: Filter non-plugins out
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the module discovers plugins in the plugins directories, it
considers all applications there. There are actual RabbitMQ plugins,
their dependencies, and possibly other applications which are neither
plugins nor dependencies.
So far, this was the case of `syslog` which could be used by Lager if
the user configures it. To make sure `rabbit_plugins` or
rabbitmq-plugins(8) didn't mess with `syslog`, there was a hard-coded
filtering function which excluded this specific application.
In RabbitMQ Enterprise Edition, we want to add another application
of this kind: `inet_tcp_compress_dist`. This application implements
an Erlang distribution protocol, so it is effectively unrelated to
RabbitMQ. However, to keep packaging simple, it is provided in the
plugins directory.
We could add it to the hard-coded filtering function, but instead this
function is replaced by the following logic to filter plugins:
* Applications which depend on `rabbit` are considered actual plugins.
* Plugins' dependencies, direct and indirect, are considered plugins
as well.
Therefore, `rabbit_plugins` will ignore:
* Applications which don't depend on `rabbit` and no plugins
depend on them (again, directly or indirectly)
* Applications which are part of Erlang/OTP.
This means the behavior slightly changes: a plugin which didn't declare
its dependency to `rabbit` will not be considered a plugin anymore. I
consider it is a bug in the plugin in the first place.
The code will log the following debug messages to list ignored
applications:
2020-01-14 13:18:41.468 [debug] <0.941.0> Plugins discovery: ignoring getopt, not a RabbitMQ plugin
2020-01-14 13:18:41.468 [debug] <0.941.0> Plugins discovery: ignoring inet_tcp_compress_dist, not a RabbitMQ plugin
2020-01-14 13:18:41.468 [debug] <0.941.0> Plugins discovery: ignoring lz4, not a RabbitMQ plugin
2020-01-14 13:18:41.468 [debug] <0.941.0> Plugins discovery: ignoring syslog, not a RabbitMQ plugin
2020-01-14 13:18:41.468 [debug] <0.941.0> Plugins discovery: ignoring zstd, not a RabbitMQ plugin
|
| |\
| |
| | |
Filter policies that cannot be applied to quorum queues
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Some policies, such as highly available, do not apply to all types of queues.
Even though quorum queues ignores some policies, they're still listed as
an applied policy on this type of queue. This commit ignores filters these
policies when applied, so they'll never be listed on the wrong type of queue.
[#169811193]
|
| | |
| |
| |
| |
| | |
This reduces the time it takes to generate the feature flags registry.
On my laptop, it goes from 830 ms to 235 ms.
|
| | |
| |
| |
| |
| |
| |
| | |
... instead of `prelaunch` category only. This allows to see the
messages logged to the new `feature_flags` category as they are logged
before the final configuration of logging (because logging requires
configuration which requires feature flags).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows use to turn on/off and change the log level of the feature
flags subsystem specifically
While here, add two messages to log the time it took to query module
attributes (i.e. to find supported feature flags) and to regenerate the
registry (i.e. generate, compile and reload the rabbit_ff_registry
module).
|
| |\ \
| | |
| | | |
Autoheal: the "autoheal_safe_to_start" state transition is not guaranteed to arrive on time
|
| | | |
| | |
| | |
| | | |
In continuation to #2208.
|
| | | |
| | |
| | |
| | | |
the winner
|
| |/ / |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This is a left-over when the code was moved from `rabbit_ff_extra` to
`rabbit_feature_flags`.
|
| | |
| |
| |
| | |
Per discussion with @dumbbell.
|
| | | |
|
| |\ \
| |/
|/| |
Chang proxy protocol error message to debug
|
| |/
|
|
| |
Fixes VESC-959
|
| |\
| |
| | |
Ensure powershell.exe runs without profile
|
| |/
|
|
|
|
| |
Also ensure non-interactive behavior.
Fixes issue where my powershell profile tries to start up ssh-agent.exe
|
| |
|
|
|
|
|
|
| |
Since rabbitmq/rabbitmq-server#2195, rabbit_recovery_terms:open_table/1
returns `ok` instead of dets:open_file/2 return value.
This should fix the upgrade from RabbitMQ 3.6.x to 3.8.x where the
message store is converted.
|
| |
|
|
| |
A couple tabs are replaced by spaces.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
and won't pass in mixed version cluster tests.
|
| | |
|
| |
|
|
|
| |
We need to find another way to screw virtual host
recovery post-#2195.
|
