Bug 44285 - ssl.SessionId Cache Control
Summary: ssl.SessionId Cache Control
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Connectors (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-23 05:29 UTC by Yuval Perlov
Modified: 2008-12-31 05:38 UTC (History)
1 user (show)



Attachments
Add sslSessionCacheSize and sslSessionTimeout attributes to <Connector> (1.90 KB, patch)
2008-07-11 14:13 UTC, Chris Elving
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.