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.
[email protected]/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’
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________
