[rabbitmq-discuss] Plugin startup behavior issue

Tue Jun 17 18:24:11 BST 2014

On 17/06/2014 3:29PM, Gavin M. Roy wrote:
> As a first step I commented out (then removed) all logging from the plugin:
> Unfortunately I am still getting the same error. Any other ideas?

Ah.

I have replicated the problem now, and it's weirder (and a bit more 
awkward) than I initially thought.

The problem is actually that your pgsql_listen_supervisor starts a 
mirrored supervisor. This then writes its state to Mnesia before the 
empty_db_check happens. The empty_db_check will only create the default 
vhost etc if all tables are empty. Since the mirrored_supervisor table 
is not, we have no vhost and the logger explodes on startup (but it's 
not really anything to do with the logger, that's just the first thing 
to hit the problem).

So I wondered about working round this by setting 
pgsql_listen_supervisor to require empty_db_check. That works fine... as 
long as the management plugin isn't enabled. If it is, then 
load_definitions wants empty_db_check after recovery, which is after 
pgsql_listen_exchange and we have a cyclic dependency.

Probably the right solution is for the empty_db_check to only check for 
absent vhosts and exchanges. I'll file a bug for that.

But how can you work around this? I don't think you can tweak the boot 
steps required by your supervisor, but I think:

diff --git a/src/pgsql_listen_sup.erl b/src/pgsql_listen_sup.erl
index ea6a11f..fc293b0 100644
--- a/src/pgsql_listen_sup.erl
+++ b/src/pgsql_listen_sup.erl
@@ -25,6 +25,7 @@
  -include_lib("rabbit_common/include/rabbit.hrl").

  start_link() ->
+    rabbit:maybe_insert_default_data(),
     mirrored_supervisor:start_link(
       {local, ?MODULE}, ?MODULE,
       fun rabbit_misc:execute_mnesia_transaction/1,

is a reasonable workaround.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, Pivotal
