[ejabberd] thread safety of MUC restoration in a cluster
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 :)
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).
> Evgeniy Khramtsov, ProcessOne.
> xmpp:xram at jabber.ru.
> ejabberd mailing list
> ejabberd at jabber.ru
More information about the ejabberd