Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v753)
In-Reply-To: 
 <2828B04F0113CD468E6D1D51DF4362A4049533BF@USEA-EXCH2.na.uis.unisys.com>
References: <B613375E-35DE-49A8-8EF6-7389AC505AE2@r-u-on.com>
 <2828B04F0113CD468E6D1D51DF4362A4049533BF@USEA-EXCH2.na.uis.unisys.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <BFE97644-F414-4758-98E6-0E791D1BCDA8@r-u-on.com>
Content-Transfer-Encoding: 7bit
From: Yuval Perlov <yuval@r-u-on.com>
Subject: Re: ssl.SessionId Cache keeps growing
Date: Tue, 22 Jan 2008 09:17:50 +0200
To: "Tomcat Users List" <users@tomcat.apache.org>

>
> 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