Environment:

CAS 3.4.3
SQL Server 2008
c3p0-0.9.1.2
Tomcat 6.0.29
JDK 1.6.0_17

We've been load testing a new CAS installation based on a mildly aggressive 
estimate of the predicted number of users for the services we plan on 
front-ending with CAS.  Our load will be much higher than the average 
institution that has deployed CAS and we have run into OutOfMemory exceptions 
during the DefaultTicketRegistryCleaner utilizing the JpaTicketRegistry.  Even 
after allocating 4G of memory to the VM.  

As discussed in previous threads, our problem lies in the fact that the 
DefaultTicketRegistryCleaner loads the whole database into memory and then 
iterates over each ticket, creating a new list of expired tickets, then 
iterates over the new list (without releasing the old list) and reloads each of 
the items to be cleaned before cleaning it.  This will likely get worse if we 
enable "Remember Me" since some tickets will live much longer than a session 
and continue to expand the number of tickets loaded for each cleanup cycle.  As 
a short term fix, we have turned off the DefaultTicketRegistryCleaner and 
created a SQL Server job that runs every hour and cleans up any ticket whose 
LAST_TIME_USED is 3 hours old.  

Unfortunately, this has required us to remove the "Remember Me" feature since 
the standard implementation relies on alternate expiration policies for 
"Normal" and "Remember Me" tickets.  Since these expiration policies are stored 
as blobs in the database, there isn't a clean way to detect what policy is 
being used from the SQL Server side.  While we have mused on ways to scan the 
blobs to determine which policy is being used, we have yet to choose that path 
and therefore "Remember Me" is disabled for our initial release.

It is a requirement for us that "Remember Me" make an appearance in a following 
update.  Therefore, I am investigating options for a scalable ticket registry 
cleanup that respects the various expiration policies that are available for 
CAS.  Has any work been done to rethink the current cleanup scheme in terms of 
scalability?  Has anyone implemented their own solution?  Any help will be 
appreciated.  If our solution ends up being both scalable and general enough, 
we would be more than willing to submit it back to the CAS community.

Thanks in advance

--
Tom Talbott
Serials Solutions


-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to