XSF Discussion - 2019-06-19

Zash, so wait. if i reboot prosody everyone stays in the room? as long as they don’t send errors which i guess under normal circumstances they shouldn't

That's what's happening in M-Link too in MUC rework we've got underway.

right. so i guess this would cover a lot of the cases except for when during downtime I try to (re)connect to a muc, get 'server not found' and then don’t know when it is fine to try again

but it it would at least solve the ghost room problem

I’m not sure how well it works in practice

but I guess that’s the point of it (that you don’t notice a graceful restart anymore) ✏

i think it might even break in the case where i have a reconnect (with the same resource) during down time. i will get a server not found back from my own server. thus my client thinks i'm not in the room. but after restart the room thinks i'm in it

and then messages sent to me won’t get bounced (by my server) because my resource is the same

but then you’re still confused on the client side (which you can fix up)

with a rejoin probably, because you threw state away

yes. so clients need extra logic that a message (or presence) received to a room that seems to be offline should trigger a ping/join

or something

which is ok i guess

but needs to be handled (and probably documented)

Restarts are usually so quick that you don't notice them.

(Unless you're silently dropped from the room)

Kev, depends on what is restarted ;)

if it’s your own server, you’ll definitely notice. if the server is being fully rebooted, it can take minutes

Don't we already have enough "works most of the time" cases?

in what cases would this break?

Daniel, I’m not sure I understand your last example, in most cases if your client reuses a previous resource, it’ll have the MUC in bookmarks and join it again afterwards, right?

In doing so, it sends a MUC join and the service then knows it has to send the full room state again, and can consider the previous full JID as out of the room.

And when your new client doesn’t know it should join the MUC, it can send back an error to any groupchat message it receives from that room.

Or am I missing something?

Link Mauve, daniels scenario was that the muc is currently rebooting while the client reconnects

thus the rejoin gets bounced with remote-server-not-found

and never reaches the MUC service

Ah right.

Yeah, then you have to try again with exponential back off, like in any current case of remote-server-not-found.

Link Mauve, but then the MUC service comes back and starts sending you type="groupchat" and presence

Probably the MUC service should ping persisted occupants after a restart

and by ping, probably I mean probe

In Prosody, that's already what sorta happens since rooms are usually restored from storage by some event that results in a broadcast.

Daniel Yes, everyone stays in the room. Rooms can be saved to disk and removed from memory and then brought back at any time for a few different reasons, of which graceful shutdown is only one.

When all goes well, nobody notices.

The situation where the room thinks you're stil there but the client doesn't think so only happens because the move to long-term stable resources. If you get a new resource every time you connect, this takes care of itself eventually via kick-causing error bounces.

the move to long term stable resources only happened because otherwise we have no ability to kick the old one

I don't think that's true

that this was the reason or that we have no way of kicking the old?

Removal of stale sessions can be done, dwd has written stuff about this before.

And they should get removed eventually anyways

Like, the server could ping existing sessions when a new session connects.

fwiw if that's what it takes i'm fine with moving to random resources

users will hate it

As always, there are tradeoffs

Ping existing sessions sounds ugly to me.

A problem in practice I see is the delay. Stanzas queued for the old session won't be resent before the ping times out.

Zash, is this prosody 0.11 or current development?

Everyone being kicked from rooms all the time because "Disconnected: Replaced by new connection" is also ugly

Daniel Theoretical

Zash, the storing muc state i mean

not the pinging of resources

Daniel, 0.11 this one.

Yes, 0.11

Rooms can be saved to disk on graceful shutdown, module unload (and reload) or when they are evicted from a LRU cache.

can or will?

does this need to be configured?

Will. Enabled by default. I'd have to check docs or code to remember details of what can be configured.

You're not worried about the init system killing the graceful shutdown due to timeout on servers with large/many rooms?

do you have any grasp on how well that works in practice? because i still have countless users telling me about ghost mucs. but of course it might be that they are all on ejabberd

countless ~= 3

Holger: Dunno, should we be?

but they are very annoying about it :-)

Loud minority?

Zash: That's the main reason that made me hesitate to implement thing.

*the same thing.

I suspect that ejabberds closing of idle s2s connections isn't helpful here.

why? saving state doesn’t require sending something over s2s does it?

I mean about ghost rooms/users. s2s connection gets closed and then fails to be reestablished for something, and then ghosts.

Yeah, I’ve often been kicked out from (old) Ejabberd rooms without being notified, this doesn’t happen much lately.

If reconnecting fails I'd assume the old connection would've been lost as well.

There's more likely that an unavailable presence can be delivered over an established s2s connection than if it has to reestablish it again.

Prosody in some configurations doesn't even manage to send anything when shutting down, making this worse.

Either way, personally I'd still prefer MUC Push over all these solutions that try to work around all these problems with MUC relying on presence.

The only real corner case I see with this is the first participant who'd like to write a groupchat message after MUC service restart.

Holger, the question is if muc push really becomes the go to thing and all clients enable 1-2 push targets on every join wouldn’t the load on the db be the same as persisting presence?

Fixing that might require some client-side hack, or waiting for MIX.

I did start on an experimental hack that would make MUC joining account based

Daniel: Yes it's just a more robust solution, in my book. As you can't do the presence thing for clients without persistent connection anyway.

(Except with the super-ugly hack of faking their presence state while they're disconnected.)

Daniel, ask MattJ about mod_devices 🙂