Thanks Scott, I will take a look at it when I get a chance. We are in the midst of our first release, so a bit distracted right now. But, this will become top of the list soon.
Thanks, -Tom On 12/9/10 8:03 PM, "Scott Battaglia" <[email protected]> wrote: 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
