[ejabberd] thread safety of MUC restoration in a cluster

Daniel Dormont dan at greywallsoftware.com
Sun Mar 6 02:53:49 MSK 2011


Thanks for the reply. It's helping shape my thoughts a bit. My main concern now is the potential disagreement between client and server with respect to presence. What I mean is that suppose client A starts the MUC and it gets initiated by the supervisor on PID <0.1.0>. But client B starts it in <0.2.0> and this is what sticks in muc_online_room. 

 For clients C, D and later this is not a problem, but subsequent packets from A will get routed to <0.2.0> which will never have gotten the initial presence from client A which means that A will never be added to the state.users which in turn means A will be treated as a non-participant. I could potentially work around this by trying to detect this state of affairs and resend the presence from A to the MUC, but it's less than ideal.

Again, if I am missing anything, any insight would be appreciated :)

dan


On Mar 4, 2011, at 9:15 PM, Evgeniy Khramtsov wrote:

> 05.03.2011 02:48, Daniel Dormont wrote:
>> I'm relatively new to Erlang, but I started looking at the code and the reason for my question is that it seems to me that since the route function in mod_muc executes a dirty read in muc_online_room (line 474) before creating and registering the new room, there's a chance for duplicate rooms being launched.
>>   
> 
> Yes, there is a problem, you are right. But in fact, there will be no duplication, because the latest launch will overwrite the previous one(s). Fixing this requires a distributive transaction which is much worse (for scalability reason).
> 
> -- 
> Regards,
> Evgeniy Khramtsov, ProcessOne.
> xmpp:xram at jabber.ru.
> 
> _______________________________________________
> ejabberd mailing list
> ejabberd at jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd



More information about the ejabberd mailing list