You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suppose Alice is in a room. The proxy keeps a copy of messages in that room and state in that room.
The messages do not need to be kept forever because clients use /messages to backfill, not /sync (beyond a brief "give me an initial timeline" of ~20 messages). The state needs to be kept for longer. Neither are needed when none of the proxy's users are joined to the room.
Nothing will go wrong if we hold on to that state. But it means the next time someone joins the room we'll hit the "gappy state" logic, which can have performance problems (see #211 et al). The "full" solution to 211 (regularly creating fresh snapshots) would avoid this, but it may be simpler to just deleting the room from the snapshots table. This would mean we create a fresh snapshot the next time we see the room.
A more nuclear approach would involve deleting all record of the room as a whole from the database. I think the tables involved are:
events
rooms
snapshots
receipts and receipts_private
txns?
spaces?
invites
If we did any of this, we'd have to ensure the delete doesn't race with another concurrent join. We'd also have to keep in-memory caches up-to-date somehow.
The text was updated successfully, but these errors were encountered:
Suppose Alice is in a room. The proxy keeps a copy of messages in that room and state in that room.
The messages do not need to be kept forever because clients use /messages to backfill, not /sync (beyond a brief "give me an initial timeline" of ~20 messages). The state needs to be kept for longer. Neither are needed when none of the proxy's users are joined to the room.
Nothing will go wrong if we hold on to that state. But it means the next time someone joins the room we'll hit the "gappy state" logic, which can have performance problems (see #211 et al). The "full" solution to 211 (regularly creating fresh snapshots) would avoid this, but it may be simpler to just deleting the room from the snapshots table. This would mean we create a fresh snapshot the next time we see the room.
A more nuclear approach would involve deleting all record of the room as a whole from the database. I think the tables involved are:
If we did any of this, we'd have to ensure the delete doesn't race with another concurrent join. We'd also have to keep in-memory caches up-to-date somehow.
The text was updated successfully, but these errors were encountered: