You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Yuval Perlov <yu...@r-u-on.com> on 2008/01/21 16:26:25 UTC
ssl.SessionId Cache keeps growing
This is a tricky one so bare with me...
We are using Tomcat 5.5 on windows running Java SSL. There are MANY
concurrent clients using SSL.
After investigating what seemed to be a memory leak and taking a
memory dump we realized that the memory is not leaking but rather
growing with a SoftReference cache (it took some courage to wait and
see that the memory stops growing about 100mb from the end).
jhat tells us our top instances are:
635474 instances of class [B
635260 instances of SoftReference
633929 instances of CacheEntry
617521 instances of com.sun.net.ssl.internal.ssl.sessionId
This block takes about 850MB! It gets there after a few days.
(do not confuse with an HttpSession problem - the sessions are
invalidated immediately but do not affect the ssl.sessionid cache).
While it doesn't create an OutOfMemoryException (since its a
SoftReference structure) it seriously affects gc performance.
I'd be really interested to know if:
1. Any one has ever met this problem?
2. Is there anyway to access the ssl.SessionId object and invalidate
it during the HttpServletRequest life cycle?
3. Anyway to limit or even disable SSL SessionId for a particular
connector (or, as a last resort to all connectors).
4. Does anyone know of a mechanism to flush all SoftReference or
limit their number?
5. Can you think of any other way to tackle this?
6. What were the guys in Sun thinking???
Thanks!
Yuval Perlov
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: ssl.SessionId Cache keeps growing
Posted by Jeff MAURY <je...@jeffmaury.com>.
As Tomcat is using JSSE, there is a way to control the size of the SSL
session's cache.
Define a property called javax.net.ssl.sessionCacheSize with a non zero
value: it will lower the total number of entries in the cache. By default,
it is 0 so no sizing is performed.
The defaut value of the ssltimeout is 86400 seconds ie 1 day. It cannot be
changed with a property (on Java5).
Regards
Jeff MAURY
Caldarale, Charles R wrote:
>
>> From: Yuval Perlov [mailto:yuval@r-u-on.com]
>> Subject: Re: ssl.SessionId Cache keeps growing
>
>> Been all over those objects thinking I can set a system
>> wide default.
>
> There is the JVM -XX:SoftRefLRUPolicyMSPerMB=n option, where n is
> defined as "Number of milliseconds per MB of free space in the heap".
> This is used to calculate the maximum time to leave a softly reachable
> object around. If you set it to zero, the SSLSessionId cache should
> disappear pretty quickly if you force a major GC every now and then.
> (The default value is 1000).
>
>> > Try an allocation of a gigantic array to force
>> > SoftReferences to be discarded, then clear the
>> > reference to the array, and force another GC.
>> > Ugly, and it probably has really nasty side
>> > effects.
>>
>> This is creative but extremely dangerous since I don't know how much
>> real free memory I have.
>
> Doesn't matter - the goal is to force an allocation failure thereby
> causing a major GC that also processes SoftReference objects. A normal
> System.gc() call won't do that, since there's no allocation failure
> involved. The second major GC is required to ensure the SoftReference
> referents are actually released (not sure if that's still needed with
> the current GC algorithms).
>
>> > Submit an enhancement request, preferably with a patch for new
>> > attributes on the <Contector> elements to control the behavior.
>>
>> How do I do that?
>
> http://tomcat.apache.org/bugreport.html
>
>> I have a feeling they are keeping the SoftReferences even
>> after their default time has elapsed
>
> I suspect the default time limit for SSLSession cache, like the default
> space limit, is infinite.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/ssl.SessionId-Cache-keeps-growing-tp14999824p15839466.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: ssl.SessionId Cache keeps growing
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Yuval Perlov [mailto:yuval@r-u-on.com]
> Subject: Re: ssl.SessionId Cache keeps growing
> Been all over those objects thinking I can set a system
> wide default.
There is the JVM -XX:SoftRefLRUPolicyMSPerMB=n option, where n is
defined as "Number of milliseconds per MB of free space in the heap".
This is used to calculate the maximum time to leave a softly reachable
object around. If you set it to zero, the SSLSessionId cache should
disappear pretty quickly if you force a major GC every now and then.
(The default value is 1000).
> > Try an allocation of a gigantic array to force
> > SoftReferences to be discarded, then clear the
> > reference to the array, and force another GC.
> > Ugly, and it probably has really nasty side
> > effects.
>
> This is creative but extremely dangerous since I don't know how much
> real free memory I have.
Doesn't matter - the goal is to force an allocation failure thereby
causing a major GC that also processes SoftReference objects. A normal
System.gc() call won't do that, since there's no allocation failure
involved. The second major GC is required to ensure the SoftReference
referents are actually released (not sure if that's still needed with
the current GC algorithms).
> > Submit an enhancement request, preferably with a patch for new
> > attributes on the <Contector> elements to control the behavior.
>
> How do I do that?
http://tomcat.apache.org/bugreport.html
> I have a feeling they are keeping the SoftReferences even
> after their default time has elapsed
I suspect the default time limit for SSLSession cache, like the default
space limit, is infinite.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ssl.SessionId Cache keeps growing
Posted by Yuval Perlov <yu...@r-u-on.com>.
>
> On Jan 21, 2008, at 11:50 PM, Caldarale, Charles R wrote:
>
>> From: Yuval Perlov [mailto:yuval@r-u-on.com]
>> Subject: ssl.SessionId Cache keeps growing
>>
>> 1. Any one has ever met this problem?
>
> I haven't, but it's definitely an interesting one.
>
>> 2. Is there anyway to access the ssl.SessionId object and invalidate
>> it during the HttpServletRequest life cycle?
>
> Couldn't find any such mechanism in the Tomcat code, but I didn't
> do an
> exhaustive search.
>
>> 3. Anyway to limit or even disable SSL SessionId for a particular
>> connector (or, as a last resort to all connectors).
>
> There is such a mechanism in JSSE, but Tomcat doesn't appear to use
> it.
> The class (interface) of interest is javax.net.ssl.SSLSessionContext,
> and the relevant methods are setSessionCacheSize() and
> setSessionTimeout(). Tomcat does not seem to have any references to
> SSLSessionContext, although the pertinent object could be retrieved
> via
> the getServerSessionContext() of javax.net.ssl.SSLContext, which
> Tomcat
> does use. (But don't confuse this SSLContext with the two others from
> different packages.)
Been all over those objects thinking I can set a system wide default.
Couldn't :-)
>
>> 4. Does anyone know of a mechanism to flush all SoftReference or
>> limit their number?
>
> Try an allocation of a gigantic array to force SoftReferences to be
> discarded, then clear the reference to the array, and force another
> GC.
> Ugly, and it probably has really nasty side effects.
This is creative but extremely dangerous since I don't know how much
real free memory I have.
I will combine this approach with SoftReference - i.e. will create
many smaller arrays and SoftReference them. I think the SoftReference
cache is LRU so once my first array disappears I know I have full
control of the cache. Ugly but might just have one less side effect.
Thanks!
>
>> 5. Can you think of any other way to tackle this?
>
> Submit an enhancement request, preferably with a patch for new
> attributes on the <Contector> elements to control the behavior.
How do I do that?
>
>> 6. What were the guys in Sun thinking???
>
> Looks like Sun provided the necessary hooks, but the defaults
> (infinite)
> are a mite questionable. I was hoping for a system property or two
> that
> might be used to specify the values, but couldn't find any (which
> doesn't necessarily mean they're not there).
I have a feeling they are keeping the SoftReferences even after their
default time has elapsed just by looking at the numbers in cache and
estimating the size of my client population. Also by the fact that it
takes several days for the cache to build up. It seems to me like
someone in sun thought there is no downside to keeping all this junk
in memory if it is soft.
Yuval Perlov
www.r-u-on.com
>
> - Chuck
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: ssl.SessionId Cache keeps growing
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jonadan [mailto:jonadanowens@yahoo.com]
> Subject: Re: ssl.SessionId Cache keeps growing
>
> There are alternative designs than using sessions!
Not in this case. Don't confuse HTTPSession with SSLSession - the
former is managed by Tomcat and can be avoided as you state, the latter
is purely internal to SSL processing inside Sun's default JSSE provider
and has to exist to support any SSL traffic.
There are APIs available to control the size and lifetime of the
SSLSessionId cache, but Tomcat does not at this point utilize them, and
Sun's defaults appear to be infinity for both time and space.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ssl.SessionId Cache keeps growing
Posted by Jonadan <jo...@yahoo.com>.
There are alternative designs than using sessions!
If the problem is that serious, you might consider
other options.
Regards.
Yuval Perlov wrote:
>
> On a side note, I'd like to argue that if you have users logging in,
> you can't help having some kind of object on the server side telling
> you which user is actually sending the request.
>
--
View this message in context: http://www.nabble.com/ssl.SessionId-Cache-keeps-growing-tp14999824p15014379.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ssl.SessionId Cache keeps growing
Posted by Yuval Perlov <yu...@r-u-on.com>.
Well, this is not session problems I am having but SSL Sessions - you
can't have a secure connection without using one of those.
On a side note, I'd like to argue that if you have users logging in,
you can't help having some kind of object on the server side telling
you which user is actually sending the request.
Yuval Perlov
www.r-u-on.com
On Jan 22, 2008, at 3:42 AM, Jonadan wrote:
IMHO, there isn't much you can do about once you use sessions. The
problem
with session is that there is no natural way telling that session is
ended
and can be discarded! So system may have to keep session objects for
long.
For this reason, I always avoid to use sessions. If this is a major
problem
for you, alternative techniques might be worth trying!
Regards.
--
View this message in context: http://www.nabble.com/ssl.SessionId-
Cache-keeps-growing-tp14999824p15010907.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: ssl.SessionId Cache keeps growing
Posted by Jonadan <jo...@yahoo.com>.
IMHO, there isn't much you can do about once you use sessions. The problem
with session is that there is no natural way telling that session is ended
and can be discarded! So system may have to keep session objects for long.
For this reason, I always avoid to use sessions. If this is a major problem
for you, alternative techniques might be worth trying!
Regards.
--
View this message in context: http://www.nabble.com/ssl.SessionId-Cache-keeps-growing-tp14999824p15010907.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: ssl.SessionId Cache keeps growing
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Yuval Perlov [mailto:yuval@r-u-on.com]
> Subject: ssl.SessionId Cache keeps growing
>
> 1. Any one has ever met this problem?
I haven't, but it's definitely an interesting one.
> 2. Is there anyway to access the ssl.SessionId object and invalidate
> it during the HttpServletRequest life cycle?
Couldn't find any such mechanism in the Tomcat code, but I didn't do an
exhaustive search.
> 3. Anyway to limit or even disable SSL SessionId for a particular
> connector (or, as a last resort to all connectors).
There is such a mechanism in JSSE, but Tomcat doesn't appear to use it.
The class (interface) of interest is javax.net.ssl.SSLSessionContext,
and the relevant methods are setSessionCacheSize() and
setSessionTimeout(). Tomcat does not seem to have any references to
SSLSessionContext, although the pertinent object could be retrieved via
the getServerSessionContext() of javax.net.ssl.SSLContext, which Tomcat
does use. (But don't confuse this SSLContext with the two others from
different packages.)
> 4. Does anyone know of a mechanism to flush all SoftReference or
> limit their number?
Try an allocation of a gigantic array to force SoftReferences to be
discarded, then clear the reference to the array, and force another GC.
Ugly, and it probably has really nasty side effects.
> 5. Can you think of any other way to tackle this?
Submit an enhancement request, preferably with a patch for new
attributes on the <Contector> elements to control the behavior.
> 6. What were the guys in Sun thinking???
Looks like Sun provided the necessary hooks, but the defaults (infinite)
are a mite questionable. I was hoping for a system property or two that
might be used to specify the values, but couldn't find any (which
doesn't necessarily mean they're not there).
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org