[jdev] How do I know when a MUC server restarts?

[Florent Le Coz]

On 03/03/2016 02:19 PM, Stephen Paul Weber wrote:
> I am writing a external component (using it with Prosody right now) 
> that allows users to join MUCs on other servers.  When a remote server 
> restarts, I see this is my prosody log:
>
> info    outgoing s2s stream singpolyma.net->chat.yax.im closed: 
> system-shutdown (Received SIGTERM)
>
> Now, my component is not running on singpolyma.net (that is a 
> different domain on the same Prosody instance), but either maybe all 
> s2s were incoming at the time since no one had said anything recently?
>
> Anyway, looking at the logs on my component, I don't see any stanza 
> indicating anything about this.  I mean, I guess that makes sense.  
> Server restarts don't generate stanzas.
>
> The problem is that when they restart the server, it comes back up 
> with all MUCs empty and I need to get everyone on my component to 
> re-join.  But as it the component actually thinks they are still in 
> the MUC!
>
> Other XMPP clients I use seem to (sometimes after awhile) detect this 
> situation somehow and tell me I'm no longer in the room (or try to 
> re-join).  How are they doing this?  Is this some quirk of the 
> external component protocol where normally Prosody would generate this 
> kind of stanza to a client?  Or what else could I be missing?  I 
> really need to solve this issue...
>
> Many thanks for any help!
>

I’m also interested by this issue, this is annoying for the users. I 
already asked for ways to solve this (on the jdev@ muc, for example, I 
believe), and the conclusion was to ping my own in-room JID (e.g. 
jdev at conference.example.com/MyNick) once in a while.

If the room considers that the client is not in the room, then it should 
get an error instead of a ping result.

That’s what poezio does. It has some issues, though (notably, with some 
“buggy” servers, when you’re connected behind the same nick, with two 
different full-jid, and you send the ping request to yourself, the room 
may route the result to the wrong resource (i.e not the one who sent the 
request), and then the client falsely believes that it is not connected 
to the room).

I wish there was a better solution.

-- 
louiz’