Home » Forums » ejabberd & XMPP » ejabberd Administration

Persistent MUC not failing over to clustered node

Submitted by dandormont on Thu, 2011-02-17 21:48

I have ejabberd running across two nodes and I followed the clustering instructions more or less according to the manual: http://www.process-one.net/docs/ejabberd/guide_en.html#htoc91 I'm able to create a MUC on "second" and have users connected to both "first" and "second" join it. When node "second" is brought down, I'd expect that users connected to that node are (temporarily, anyway) removed from the MUC. No problem. But I would expect that users logged into the MUC on "first" are able to continue using the room, because the room would fail over to "first." But instead the users receive a "disconnected" message, specifically:

<presence from="dansroom@conference.mydomain/dan" type="unavailable" to="dan@mydomain/resource" >
<x xmlns="http://jabber.org/protocol/muc#user">
<item affiliation="none" role="none" >
<reason>You are being removed from the room because of a system shutdown</reason>
</item>
<status code="332" />
</x>
</presence>

Is there a way to get this to work? Am I misunderstanding what it means for the multi-user chat module to be clustered?

‹ service-unavailable in response to IQ from external user Yum Ejabberd Install = no package found ›

I researched this a little

Submitted by dandormont on Fri, 2011-02-18 16:47.

I researched this a little more on my own and found that as long as I set the muc tables to ram and disk copy on "second" then at least the configuration of the room carries over, but there are two things I'd like to see if I can get past:

  1. The client has to explicitly rejoin the MUC in order for it to be properly recreated on the clustered server. Since the client is still logged in, I was hoping that the MUC would at least appear to be still live and the client would not get the "shutdown" message I mentioned above.
  2. It appears that the history of the MUC is not clustered. Is there any way to achieve that, short of hacking mod_muc (which I'm hesitant to do since I don't know Erlang)?

Any thoughts would be appreciated.

»

Can someone help

Submitted by dandormont on Thu, 2011-02-24 02:34.

Does anyone have any ideas on this issue? I understand that auto-archiving to the database of persistent MUC history is a feature that doesn't currently exist. That's ok. But I'm still hoping there's a way my client does not have to explicitly rejoin the room when the node *that* client is connected to is still live. thanks

»
Syndicate content

User login