|Summary:||ssl.SessionId Cache Control|
|Product:||Tomcat 6||Reporter:||Yuval Perlov <yuvalperlov>|
|Component:||Connectors||Assignee:||Tomcat Developers Mailing List <dev>|
|Attachments:||Add sslSessionCacheSize and sslSessionTimeout attributes to <Connector>|
Description Yuval Perlov 2008-01-23 05:29:19 UTC
There is no way to control the ssl.SessionId cache size. The default Sun JVM behavior is too keep a SoftReference cache that grows as much as it can. This has a performance impact since the GC works harder because of the heap size. The result is that with a system that has a lot of https clients, the memory grows to a very large size: We have 700K of SessionIds in memory consuming a little over 800MB !!! I think the connector should have attributes that let me control the max time and size ssl.sessionid are kept (for reference, websphere let's you do that). Another useful feature would be to let me explicitly invalidate a ssl.sessionid (during the request life cycle).
Comment 1 Mark Thomas 2008-01-24 13:13:37 UTC
Marking as an enhancement. Patches are always welcome.
Comment 2 Chris Elving 2008-07-11 14:13:20 UTC
Created attachment 22247 [details] Add sslSessionCacheSize and sslSessionTimeout attributes to <Connector>
Comment 3 Patrick Coomans 2008-11-25 06:37:08 UTC
This bug also generates a security breach when mutual SSL authentication is used with a certificate on a smartcard. When the card is removed from the computer, the session still continues. Changing this sslSessionTimeout to a low value would allow the application to detect card removal.
Comment 4 Mark Thomas 2008-12-04 11:33:29 UTC
This has been fixed in trunk and proposed for 6.0.x
Comment 5 Mark Thomas 2008-12-31 05:38:45 UTC
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.