DanielZash, 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
KevThat's what's happening in M-Link too in MUC rework we've got underway.
COM8has joined
Danielright. 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
COM8has left
Danielbut it it would at least solve the ghost room problem
jonas’I’m not sure how well it works in practice
jonas’but I guess that’s the point of it (that you don’t notice a graceful restart) anymore
jonas’but I guess that’s the point of it (that you don’t notice a graceful restart anymore)
Danieli 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
Danieland then messages sent to me won’t get bounced (by my server) because my resource is the same
rtq3has left
jonas’but then you’re still confused on the client side (which you can fix up)
Douglas Terabytehas left
Douglas Terabytehas joined
rtq3has joined
jonas’with a rejoin probably, because you threw state away
neshtaxmpphas left
Danielyes. so clients need extra logic that a message (or presence) received to a room that seems to be offline should trigger a ping/join
Danielor something
Danielwhich is ok i guess
Danielbut needs to be handled (and probably documented)
Kacperhas left
neshtaxmpphas joined
Kacperhas joined
KevRestarts are usually so quick that you don't notice them.
Kev(Unless you're silently dropped from the room)
kokonoehas left
Kacperhas left
Kacperhas joined
remkohas joined
jonas’Kev, depends on what is restarted ;)
jonas’if it’s your own server, you’ll definitely notice. if the server is being fully rebooted, it can take minutes
rtq3has left
HolgerDon't we already have enough "works most of the time" cases?
remkohas left
rtq3has joined
Danielin what cases would this break?
goffihas left
Zashhas left
neshtaxmpphas left
neshtaxmpphas joined
Zashhas joined
Link MauveDaniel, 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?
Link MauveIn 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.
Link MauveAnd 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.
goffihas joined
Link MauveOr am I missing something?
jonas’Link Mauve, daniels scenario was that the muc is currently rebooting while the client reconnects
jonas’thus the rejoin gets bounced with remote-server-not-found
jonas’and never reaches the MUC service
Link MauveAh right.
Kacperhas left
Link MauveYeah, then you have to try again with exponential back off, like in any current case of remote-server-not-found.
Kacperhas joined
jonas’Link Mauve, but then the MUC service comes back and starts sending you type="groupchat" and presence
Zashhas left
kokonoehas joined
Zashhas joined
Nekithas left
Nekithas joined
debaclehas joined
pdurbinhas left
delehas joined
delehas left
neshtaxmpphas left
delehas joined
MattJProbably the MUC service should ping persisted occupants after a restart
delehas left
delehas joined
MattJand by ping, probably I mean probe
ZashIn Prosody, that's already what sorta happens since rooms are usually restored from storage by some event that results in a broadcast.
ZashDaniel 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.
ZashWhen all goes well, nobody notices.
Nekithas left
Nekithas joined
kokonoehas left
delehas left
ZashThe 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.
Danielthe move to long term stable resources only happened because otherwise we have no ability to kick the old one
ZashI don't think that's true
Danielthat this was the reason or that we have no way of kicking the old?
ZashRemoval of stale sessions can be done, dwd has written stuff about this before.
Kacperhas left
ZashAnd they should get removed eventually anyways
ZashLike, the server could ping existing sessions when a new session connects.
Danielfwiw if that's what it takes i'm fine with moving to random resources
delehas joined
Danielusers will hate it
ZashAs always, there are tradeoffs
kokonoehas joined
HolgerPing existing sessions sounds ugly to me.
Kacperhas joined
HolgerA problem in practice I see is the delay. Stanzas queued for the old session won't be resent before the ping times out.
DanielZash, is this prosody 0.11 or current development?
ZashEveryone being kicked from rooms all the time because "Disconnected: Replaced by new connection" is also ugly
ZashDaniel Theoretical
DanielZash, the storing muc state i mean
Danielnot the pinging of resources
Link MauveDaniel, 0.11 this one.
ZashYes, 0.11
ZashRooms can be saved to disk on graceful shutdown, module unload (and reload) or when they are evicted from a LRU cache.
Danielcan or will?
Danieldoes this need to be configured?
valohas left
ZashWill. Enabled by default. I'd have to check docs or code to remember details of what can be configured.
valohas joined
HolgerYou're not worried about the init system killing the graceful shutdown due to timeout on servers with large/many rooms?
Danieldo 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
Danielcountless ~= 3
ZashHolger: Dunno, should we be?
Danielbut they are very annoying about it :-)
ZashLoud minority?
HolgerZash: That's the main reason that made me hesitate to implement thing.
Holger*the same thing.
ZashI suspect that ejabberds closing of idle s2s connections isn't helpful here.
Danielwhy? saving state doesn’t require sending something over s2s does it?
delehas left
ZashI mean about ghost rooms/users. s2s connection gets closed and then fails to be reestablished for something, and then ghosts.
Link MauveYeah, I’ve often been kicked out from (old) Ejabberd rooms without being notified, this doesn’t happen much lately.
HolgerIf reconnecting fails I'd assume the old connection would've been lost as well.
delehas joined
ZashThere's more likely that an unavailable presence can be delivered over an established s2s connection than if it has to reestablish it again.
ZashProsody in some configurations doesn't even manage to send anything when shutting down, making this worse.
HolgerEither 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.
HolgerThe only real corner case I see with this is the first participant who'd like to write a groupchat message after MUC service restart.
DanielHolger, 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?
HolgerFixing that might require some client-side hack, or waiting for MIX.
ZashI did start on an experimental hack that would make MUC joining account based
HolgerDaniel: 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.
Holger(Except with the super-ugly hack of faking their presence state while they're disconnected.)
XSF Discussion - 2019-06-19