On Wed, Dec 8, 2010 at 9:18 PM, Talbott, Thomas < [email protected]> wrote:
> 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. > What is your expected load? It would be interesting to see how it compares to other deployer's loads. > > 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. > You may be at a point where the default registry isn't enough for you. In that case, feel free to write a JPA specific one that meets your needs. As long as you conform to the API, then everything should work. If you feel its general enough, I would encourage you to contribute it back. We're happy to work with you on it. We've rethought our cleanup mechanisms in 4.0, but that probably won't be out before your deployment. Cheers, Scott > > 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 > > -- 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
