We have already seen an issue before where the SSL client-side cache would grow apparently without bounds, because some sessions were being stored into it that could never be restarted. Those sessions were not getting freed until the next day, after the SSL session expired. This issue was https://bugzilla.mozilla.org/show_bug.cgi?id=273993 . The fix that was done was to stop storing those useless sessions. We now have another problem, which I discovered while coding my strsclnt enhancements as part of bug 292151 . Using SSL_SetSocketPeerID, it is possible to split the client cache into different compartments. The feature is used in clients when connecting to different hosts through a proxy for example. The problem is that the compartments never get freed until the sessions expire, even if they are no longer used. IMO, this is a major problem. It prevents me from using this feature in strsclnt to resume a recent session. But the problem isn't specific to this strsclnt case. It really applies to any client application. Unlike the SSL server cache, the SSL client cache size isn't limited . There is no API currently to set it upfront. I haven't found an API to set the lifetime of client-side SSL sessions either. If there is one, it could mitigate the problem quite a bit, since the purge routine could take care of the issue without having to set an absolute size limit on the client cache.
Note that in bug 292151, I experienced not only heap growth but a huge performance drop rapidly. I believe it is due to the purging algorithm, which examines all the client cache entries expiration time linearly for each lookup. So, even if there is plenty of memory available, performance degrades unreasonable because of the client cache size, and something needs to be done about it.
The issues here are really cache search efficiency and size bounding. Shortening timeout times would be just a workaround. I agree that the size should be bounded. It should also be made a true LRU, disarding the least recently used, not the oldest, SID when the cache reaches a size bound. I agree the problem is serious enough that if affects how we implement RFE 292151. But I don't think this is P1 for 3.11. We wouldn't stop the 3.11 release for it, IMO.
Priority: P1 → P2
I thought this bug was worthy of P1 because customers have experienced problems related to this problem in the field that have resulted in high-visibility escalations. This bug is a chance to work around all related issues. I don't know if we would stop the release for it, but I would like to see this as a high priority for an upcoming release, even if it's not necessarily 3.11 .
The escalated problem was bug 273993, not this bug. It's already fixed. The change proposed here might have further helped to mask the problem seen in that case, but masking application bugs is not an objective of this bug.
*** Bug 274989 has been marked as a duplicate of this bug. ***
remove target milestone, since the target was missed.
Target Milestone: 3.11 → ---
You need to log in before you can comment on or make changes to this bug.