Thomas, You can look in trunk (the TicketRegistry has been renamed SessionStorage). The short version is that the storage mechanisms are now responsible for their clean up algorithms rather than exposing a way to get tickets such than an external/generic mechanism can do clean up. This made sense for a number of reasons:
1. Not every storage needs an external mechanism to clean it (i.e. memcached) 2. There are some limitations/optimizations specific to the type of storage mechanism. With regards to #2, the JPA example in the trunk does its removal via a query (since we fixed how we store the entities). This limits us in some sense ( you can't do overly complex clean up mechanisms like relying on the isExpired method) but it allows you to replicate the basic ExpirationPolicies (i.e. count and timeout) with a query. On Thu, Dec 9, 2010 at 4:52 PM, Talbott, Thomas < [email protected]> wrote: > Marvin & Scott, > > Thanks for your replies. The load we were testing for was 500 concurrent > users (yes, concurrent authentication users) across two load balanced CAS > servers. Off the top of our heads, we were seeing anything from 9,000 to > 23,000 tickets being cleaned up every hour. Unfortunately, our test > environment has been refreshed and we lost the logs. > > My Initial looking into the current API (like the TicketRegistry interface) > definitely reveals its limitations, which is why I posed the question about > future thought. It is good to know that you are looking at this issue for > CAS 4.0. It would help inform my strategy if you had a projection of when > 4.0 is likely to be available. Also, is this implementation available in > the source repository so that I can understand where you will be taking the > cleanup process? > > Thanks, > -Tom > > > On 12/9/10 8:02 AM, "Marvin Addison" <[email protected]> wrote: > > >> Has any work been done to rethink the current cleanup scheme in terms of > >> scalability? > > > > Yes, but as Scott mentioned it requires some API changes that are > > slated for CAS 4.0. The core of the issue is that ticket expiration > > policy logic is not persisted to the database, so a solution like the > > most desirable DELETE * FROM TGT WHERE EXPIRED=1 is not possible. > > > >> 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. > > > > The best you could do would be to handle deletion in chunks, where the > > number of tickets evaluated for cleanup is always a safe value given > > your memory constraints. That seems like a very natural extension of > > the existing cleaner, and off the top of my head would only require > > one additional database field to track the last ticket visited. > > > > If you intend to work on this, it would be helpful if you filed a Jira > > issue for improvement at https://issues.jasig.org/browse/CAS and > > attached a patch; that is the best way to contribute your work back to > > the product. It would also provide an opportunity for community > > review and feedback. I would personally be very interested to review > > your solution. > > > > M > > > > -- > 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
