Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sliding sync: Add classes for per-connection state #17574
Sliding sync: Add classes for per-connection state #17574
Changes from 4 commits
da5339d
baac6c5
0561c86
2e7672d
64310ec
79e80eb
d982efe
b0a5c0e
577370a
27b7a4a
dec5314
5b6755a
7f5bccc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name
RoomStatusesForStream
is confusing because it implies that it maps from room status to stream or vice versa. But it actually keeps track ofroom_id
to whether we have sent this room down the connection before.And elsewhere, we have one for each type of stream that we want to track things in (
rooms
andreceipts
).Perhaps just
RoomStatusMap
orHaveSentRoomMap
(docstring could also be updated)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've renamed to
RoomStatusMap
. I think in future we might want to renameHaveSentRoom
to something else (as e.g. trackingtimeline_limit
doesn't fit into the name really).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we worried about the memory footprint over time? For a long-running connection, this seems like it will grow and grow until we restart the server. Every sync request with updates will add another layer to this
ChainMap
.There's never a chance to garbage collect anything even once a map layer is completely superseded by the layers below with all of the keys. Seems like we should do a clean-up /consolidation pass after a certain number of layers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah so actually when we store the mutable connection state we actually end up doing a
RoomStatusesForStream.copy()
, which then flattens the chainmap into a dict again. I think that stops us from every ending up with nested chain maps like that.I'm also wanting to rip all this out and replace it with DB tables once the receipts and subscription PRs land, so I'm not overly concerned about resources for this stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, we should add some comments in various places. Something about how the
copy()
flattens theChainMap
back out.Or maybe a better word about, we only ever use the
MutablePerConnectionState
during the lifetime of the request and always end up making a flatPerConnectionState
copy before we store it in theConnectionStore
.Because we
record_new_state(...)
(which flattens out theChainMap
) after each request, theChainMap
doesn't grow indefinitely.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, will try and add some comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have tried to add a couple of comments in 7f5bccc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having a lot of trouble keeping all of these structures straight:
SlidingSyncConnectionStore
->PerConnectionState
->RoomStatusesForStream
->HaveSentRoom
->HaveSentRoomFlag
Maybe it's just a naming thing or because this is my first exposure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's a lot. I don't know if maybe it'd help moving to a different file so its a bit more clearly laid out? Suggestions on naming is also more than welcome.