[ejabberd] Mnesia and Pids

Mickael Remond mickael.remond at erlang-fr.org
Wed Nov 16 10:56:34 MSK 2005


* Matthew Reilly <matthew.reilly at sipphone.com> [2005-11-15 13:32:26 -0800]:

> I discovered an odd behavior with Mnesia/OTP and I don't know if this is
> a bug with Mnesia/Erlang/OTP or something I'm missing.
> 
> I was playing around with ejabberd configuration and I accidentally
> started up an ejabberd node with odbc without first compiling ejabberd
> with odbc support. This ended up causing different clustered node to
> crash due to an out of memory error. The root cause of the crash seemed
> to either be how Mnesia stores Pids or Erlang/OTP monitors them.

I think your problem does not relates to ODBC, as you are only speaking
about Mnesia. Mnesia is not an SQL database.

[snip...]
> While the original cause was due to an application error, it seems that
> Mnesia and/or erlang/OTP should not allow a BIF to crash due to an
> application error. Either Mnesia shouldn't return an invalid Pid, or
> erlang:monitor should handle it correctly.
> 
> Is this a true bug or am I not understanding how Mnesia is supposed to
> handle Pids?
> If it is a bug, is it in Mnesia or in OTP/erlang?

In the piece of code you describe, there is nothing related to Mnesia
itself, but related to how the application code is managing its data.
The described Pid does not seem related to Mnesia internal, but to
ejabberd routing table.

> To reproduce this behavior:
> 1) Start ejabberd as normal on System A:
> 2) Force application error on System B:
> 3) Add System B as a cluster:
> 4) Start System B:
> 5) Stop System A:
> 6) Start System A:

It seems that in your recipe, you are forcing the Mnesia database to
have out of sync tables.
What happens if you stop all nodes and then restart A then B ? 

-- 
Mickaël Rémond


More information about the ejabberd mailing list