Skip to content

Commit 0c3f4bc

Browse files
committed
rabbit_peer_discovery: Register node before running discovery
[Why] The two backends that use registration are Consul and etcd. The discovery process relies on the registered nodes: they return whatever was previously registered. With the new checks and failsafes added in peer discovery in RabbitMQ 3.13.0, the fact that registration happens after running discovery breaks Consul and etcd backend. It used to work before because the first node would eventually time out waiting for a non-empty list of nodes from the backend and proceed as a standalone node, registering itself on the way. Following nodes would then discover that first node. Among the new checks, the node running discovery expects to find itself in the list of discovered nodes. Because it didn't register yet, it will never find itself. [How] The solution is to register first, then run discovery. The node should at least get itself in the discovered nodes. (cherry picked from commit cb9f0d8)
1 parent 6c00e89 commit 0c3f4bc

File tree

2 files changed

+6
-1
lines changed

2 files changed

+6
-1
lines changed

deps/rabbit/src/rabbit_db.erl

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -52,6 +52,7 @@ init() ->
5252

5353
ensure_dir_exists(),
5454
rabbit_peer_discovery:maybe_init(),
55+
rabbit_peer_discovery:maybe_register(),
5556

5657
pre_init(IsVirgin),
5758

@@ -77,7 +78,6 @@ init() ->
7778
"DB: initialization successeful",
7879
#{domain => ?RMQLOG_DOMAIN_DB}),
7980

80-
rabbit_peer_discovery:maybe_register(),
8181
init_finished(),
8282

8383
ok;

deps/rabbit_common/src/rabbit_peer_discovery_backend.erl

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -57,3 +57,8 @@
5757
-callback unlock(Data :: term()) -> ok.
5858

5959
-optional_callbacks([init/0]).
60+
61+
-export([api_version/0]).
62+
63+
api_version() ->
64+
2.

0 commit comments

Comments
 (0)