| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\ |
|
| | |\ |
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
This key is already provided by rabbit_backing_queue:info_keys/0 which
is concatenated to ?INFO_KEYS and ?STATISTICS_KEYS.
This fixes a bug where this key was duplicated in the JSON returned by
the "/api/queues" endpoint.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, only the legacy form was supported (the one existing
in Erlang up-to R13B). The user would use the following RabbitMQ
configuration:
{ssl_options, [
{verify_fun, {Module, Function}}
]}
This is converted to the following ssl option:
{ssl_options, [
{verify_fun, fun(Errors) ->
Module:Function(Errors)
end}
]}
Although this form is still supported by Erlang R14B+, this is
undocumented and some users complain about RabbitMQ not matching the
expected behaviour, according to ssl's documentation.
Now, the new form is supported as well. Here's what the user would
configure:
{ssl_options, [
{verify_fun, {Module, Function, InitialUserState}}
]}
or:
{ssl_options, [
{verify_fun, {Module, Function}}
]}
This is converted to the new form:
{ssl_options, [
{verify_fun, {fun(OtpCert, Event, State) ->
Module:Function(OtpCert, Event, State)
end,
InitialUserState
}}
]}
To determine which form to use, we look at the version of the ssl
application:
o 4.0.1+: We check if Module:Function/3 is exported and use the new
form. If Module:Function/1 is exported, we use the old form. If
both are exported, the new form is preferred. If InitialUserState
is unspecified, 'none' is used.
o Before 4.0.1: We use the legacy form only.
If Module can't be loaded or if the expected Function/Arity is not
exported, an error is logged and RabbitMQ fails to start.
|
| |\ |
|
| | |\ |
|
| | | | |
|
| | |/
| |
| |
| | |
in-memory message to delta, and do the same for beta.
|
| | |\ |
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This works around a race in Mnesia where a starting loser would hang
forever. This happens when a starting loser connects to another loser,
negotiates the Mnesia protocol and attempts to acquire a write lock on
the other node's schema. If the other nodes stops right between the
protocol negotiation and the lock request, the starting node never
receives an answer to its request.
Before this fix, the hang occurred after at most 30 minutes looping on
the partitions:autoheal test in rabbitmq-test. With the fix, RabbitMQ
survived an all night long run.
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
As any other loosing nodes, the leader must wait for the winner_is
message, instead of restarting immediately.
The previous behaviour caused transient failures in the autoheal process
if the leader was in the middle of the restart at the time the winner
checks that all loosing nodes are up and running.
|
| |\ |
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This prevents a plugin from being enabled if it won't be able to
actually run later. A use case for this is a plugin built with Erlang
version N, but executed on Erlang version M, where M isn't capable of
running the bytecode from N. This was the case with Eralng R14B vs.
R15B.
The "rabbitmq-plugins enable <plugin>" command reports the error and the
plugin remains disabled.
A node reports the error too and refuses to start, exactly as if the
plugin was missing.
|
| | |\ \
| | |/ |
|
| | | | |
|
| | |/ |
|
| | |\ |
|
| | | |\ |
|
| | | | |
| | | |
| | | |
| | | | |
it is called.
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Before this change, the node would join the cluster and the consistency
would be only checked during application restart (rabbitmqctl
start_app). This could lead to crash during the join due to Erlang,
Mnesia or RabbitMQ incompatibilities.
Now, the join_cluster command reports the problem. Here's an example:
$ rabbitmqctl join_cluster <remote_node>
Clustering node <local_node> with <remote_node> ...
Error: {inconsistent_cluster,
"OTP version mismatch: local node is R16B03-1, remote node 17.3"}
|
| | | |
| | |
| | |
| | | |
While here, remove the unused PluginVsn variable.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The goal is to make sure the right application is picked, in case the
same one is available as both a RabbitMQ plugin and an external Erlang
application. For instance, this could be the case with the Cowboy
application: a version is available in the plugins, but the user could
add an incompatible version to Erlang/OTP libdir or set ERL_LIBS to
point to it.
There's one exception currently: eldap. This application used to be
available as a 3rd party one. But since Erlang R15B01, it's included
in the standard library. We trust this version to have a stable API.
Therefore, if the node runs on R15B01 or later and eldap version is
1.0+, we use this one. In all other cases, we don't trust it and prefer
the RabbitMQ plugin.
|
| | |/
|/| |
|
| | | |
|
| | | |
|
| |\ \ |
|
| | |\ \
| | |/
| |/| |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
short disconnection since Mnesia might not detect it.
|
| | | |
| | |
| | |
| | | |
the partition it will behave wrong anyway.
|
| | |\ \
| | |/
| |/| |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
do so explicitly here.
|
| | |/ |
|
| | |
| |
| |
| | |
While here, rename the check function to a more sensible name.
|
| |/ |
|
| |\ |
|
| | |\ |
|
| | | | |
|
