rabbit_logger_exchange_h: Always declare exchange, even if exchange logging is disabled#15320
Conversation
There was a problem hiding this comment.
I have also tested locally (using selenium, the same mechanism i used to find this issue) and it works.
Test case 1: A newly created rabbitmq starts without any issues when it is configured with log.exchange = true and a definitions file containing a queue and a binding with the amq.rabbitmq.log exchange.
Test case 2: If we set log.exchange = false and restart the same rabbitmq server, even though the queue and binding and exchange remains, there is no system logging captured via the exchange.
|
I agree with the idea of unconditionally declaring the |
3e7c76f to
a63eafb
Compare
…ogging is disabled
[Why]
When the exchange logger handler is added, the broker is not ready to
declare the exchange.
The previous implementation used a temporary process that entered a loop
to wait for the broker to be ready and declare the exchange. It was
possible that definitions were imported before the exchange was
declared, leading to errors if bindings referenced it.
There was another problem: the exported definitions were dependent on
the exchange logger configuration:
* The default vhost under which the logger exchange is declared is
configurable.
* The logger exchange is only declared if the exchange logger handler is
enabled in the configuration.
Because of this, the import of definitions could fail if the
configuration of the node where the definitions are imported does not
enable the exchange logger handler.
[How]
This patch changes two things:
1. The logger exchange is always declared, regardless if exchange-based
logging is enabled or not. This also allows to get rid of the polling
in the setup process.
2. The logger exchange is included in the exported definitions.
This way, the exported definitions don't depend on any configuration on
the nodes they are imported in: the exported definitions are
self-contained and know about this logger exchange.
Part 1 could be enough to fix the problem on RabbitMQ version that
include this patch. Part 2 allows to fix the problem when definitions
are exported from a version with this patch and are imported on a
version without.
V2: Ignore the failure to declare the exchange. It should probably not
be the only logger configured because there is a chicken-and-egg
loop with it. It should not block the broker from starting.
a63eafb to
a908504
Compare
(cherry picked from commit 0ec0df1)
For 4.2.4: rabbit_logger_exchange_h: Always declare exchange, even if exchange logging is disabled (backport #15320)
Why
When the exchange logger handler is added, the broker is not ready to declare the exchange.
The previous implementation used a temporary process that entered a loop to wait for the broker to be ready and declare the exchange. It was possible that definitions were imported before the exchange was declared, leading to errors if bindings referenced it.
There was another problem: the exported definitions were dependent on the exchange logger configuration:
Because of this, the import of definitions could fail if the configuration of the node where the definitions are imported does not enable the exchange logger handler.
How
This patch changes two things:
The logger exchange is always declared, regardless if exchange-based logging is enabled or not. This also allows to get rid of the polling in the setup process.
The logger exchange is included in the exported definitions.
This way, the exported definitions don't depend on any configuration on the nodes they are imported in: the exported definitions are self-contained and know about this logger exchange.
Part 1 could be enough to fix the problem on RabbitMQ version that include this patch. Part 2 allows to fix the problem when definitions are exported from a version with this patch and are imported on a version without.