The default bug view has changed. See this FAQ.

prevent in-memory cache of collection names/ids from growing without bound

VERIFIED FIXED

Status

Cloud Services
Server: Sync
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: rfkelly, Assigned: rfkelly)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa?])

Attachments

(1 attachment)

Comment hidden (empty)
Whiteboard: [qa?]
(Assignee)

Comment 1

5 years ago
Created attachment 610808 [details] [diff] [review]
patch limiting size of in-memory collections cache

This patch adds a hard limit of 1000 items in the in-memory cache of collection names/ids.  Additional collections will continue to work, but will be slower because their details need to be looked up in the database on every request.
Attachment #610808 - Flags: review?(telliott)
Comment on attachment 610808 [details] [diff] [review]
patch limiting size of in-memory collections cache

Code is fine (no tests?), but my suspicion is that 1000 may end up too low and we may need to go to, say, 5000. Something to keep an eye on once we see the actual table size.
Attachment #610808 - Flags: review?(telliott) → review+
(Assignee)

Comment 3

5 years ago
https://github.com/mozilla-services/server-syncstorage/commit/0a700ddda0fb79e8783bfbfc1c77f8f5c88a49a4
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
:telliott or :rfkelly - did you make a final decision on 1000 vs. 5000 here?
(Assignee)

Comment 5

5 years ago
It's at 1000 in the code, I think it should be safe to leave at that for now.  Things will still work even if more than 1000 collections are created, they'll just be a bit slower.  And it's trivial to bump this number if required.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.