chadillac/ejabberd-easy_cluster

Make multi-master Ejabberd clustering possible, make it easy. Also ease the process of a slave Ejabberd node joining an existing cluster using a traditional master->slave configuration.

ejabberd-easy_cluster's Issues

test_node always reports as server not found

(ejabberd@ip-172-30-0-115)2> easy_cluster:test_node('ejabberd@172-30-1-221').
server could NOT be reached.
ok

I've confirmed that beam is listening on the private interfaces on both my nodes

ubuntu@ip-172-30-0-115:~$ sudo netstat -pant | grep beam | grep LISTEN
tcp 0 0 0.0.0.0:5269 0.0.0.0:* LISTEN 3777/beam
tcp 0 0 0.0.0.0:5280 0.0.0.0:* LISTEN 3777/beam
tcp 0 0 0.0.0.0:4000 0.0.0.0:* LISTEN 3777/beam
tcp 0 0 172.30.0.115:7777 0.0.0.0:* LISTEN 3777/beam
tcp 0 0 0.0.0.0:5222 0.0.0.0:* LISTEN 3777/beam
tcp 0 0 0.0.0.0:5223 0.0.0.0:* LISTEN 3777/beam

ubuntu@ip-172-30-1-221:/usr/lib/ejabberd/ebin$ sudo netstat -pant | grep beam | grep LISTEN
tcp 0 0 0.0.0.0:5269 0.0.0.0:* LISTEN 2454/beam
tcp 0 0 0.0.0.0:5280 0.0.0.0:* LISTEN 2454/beam
tcp 0 0 0.0.0.0:4000 0.0.0.0:* LISTEN 2454/beam
tcp 0 0 172.30.1.221:7777 0.0.0.0:* LISTEN 2454/beam
tcp 0 0 0.0.0.0:5222 0.0.0.0:* LISTEN 2454/beam
tcp 0 0 0.0.0.0:5223 0.0.0.0:* LISTEN 2454/beam

Any idea why this would be happening ??

slave nodes fail to start after a reboot

I know you don't have time to fix reported issues but I'm working on this one for a week now. Even though I don't have a solution yet, I do have some workaround that may be useful to others.
As soon as I put an ejabberd node as a slave using easy_cluster:join() function, the node works until next reboot. syslog reports the following error:
epmd: epmd: node name already occupied ejabberd
and service ejabberd live reports:
"Protocol: ~p: register error: pn",["inet_tcp",
{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},

Note I installed ejabberd from Ubuntu 12.04 packages.

First workaround:
service ejabberd stop
killall -u ejabberd
rm -f /var/run/ejabberd/ejabberd.pid
service ejabberd start

Second workaround:
Add the two following lines at the beginning of the start function in /etc/init.d/ejabberd script:
# Kill epmd if node is already registered
epmd -names | grep -q "$NAME" && pkill epmd
Then, simply run:
service ejabberd start

My current problem is that even after patching /etc/init.d/ejabberd, the slave node fails to properly start after a reboot. I thought it was simply calling this script... I even changed the runlevel of this script to start it after networking is ready, but the problem persists.

Warnings in sync_node

erlc easy_cluster.erl

easy_cluster.erl:31: Warning: variable 'NodeName' is unused
easy_cluster.erl:33: Warning: variable 'NodeName' is unused
easy_cluster.erl:33: Warning: variable 'NodeName' shadowed in generate

Inconsistent_database after a network split

I set up 3 master nodes as described in your blog. After configuring the first node (node1), I use your join_as_master method in both node2 and node3:
easy_cluster:join_as_master('ejabberd@node1').
At first glance, it works perfectly. However, after a network split, the system didn't work properly. Restarting node2 in live mode, I saw the following error message:
Mnesia(ejabberd@node2): ** ERROR ** mnesia_event got {inconsistent_database, starting_partitioned_network, ejabberd@node1}

I don' t know how to solve this problem and, more important, how to make sure the ejabberd cluster still works after a network split, without a manual intervention. Any idea?

can easy_cluster can have more than two master?

sync_node(NodeName) ->
[{Tb, mnesia:add_table_copy(Tb, node(), Type)}
|| {Tb, [{NodeName, Type}]} <- [{T, mnesia:table_info(T, where_to_commit)}
|| T <- mnesia:system_info(tables)]].

this code don't copy the NodeName's table to it's local, due to " {Tb, [{NodeName, Type}]} <- [{T, mnesia:table_info(T, where_to_commit)} " will not match any table after you have two master, there will be no table to be mnesia:add_table_copy .

am i right ?

if i don't ,
the third master don't have the table copy ， how can it be a real master ... the other two maste crash will make all the table crash.