[ejabberd] Strange MUC behavior
dan at greywallsoftware.com
Wed Apr 13 22:19:07 MSD 2011
I've been looking into this recently and can summarize with this statement: indvidual MUC rooms are not clustered. If the room is not pre-configured as persistent, it will live on the node of whichever user creates it. If that node is shut down cleanly, the room is destroyed and other users in the room will get a message to that effect. If that node is shut down uncleanly, the other node will remove the MUC from the database, but it will not know who the participants of that MUC were. So User2 will not be automatically notified. If User2 tries to send messages *after* User1 has already recreated the MUC they will fail because User2 is not an occupant of the (recreated) MUC.
The only solution I know of is to have User2 rejoin, but I'm interested in others' inputs also.
On Apr 12, 2011, at 7:22 PM, Sylvain Niles wrote:
> PS: We're running ejabberd 2.1.6, thanks!
> On Tue, Apr 12, 2011 at 4:21 PM, Sylvain Niles <sylvain.niles at gmail.com> wrote:
> We're seeing some strange MUC behavior:
> server1 & server2 = example.com
> User1 logs into server1 and creates mucroom1
> User2 logs into server2 and joins mucroom1
> server1 goes down
> User1 reconnects to server2 and rejoins mucroom1 (works fine
> User2 types chat messages into mucroom1 but they show up as system messages to User1 and User2 sees no new messages for mucroom1
> User2 rejoins room and behavior returns to normal.
> I would expect User2 to get some sort of error or a forced rejoin to the MUC instead of having to manually detect that a problem is occurring and rejoining. Any ideas on why this happens and how we can fix?
> ejabberd mailing list
> ejabberd at jabber.ru
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ejabberd