That is one of the weak points in current CAS in my opinion. Limitation still is the JPA ticket store which leads to org.hibernate.exception.LockAcquisitionException errors regularly (even with all indexes in place).
Also, as all tickets need to be deserialized currently by the ticket cleaner, we need a lot of heap space. Hope the entity model will be optimized in a future CAS version, so at least the deserialization doesn't need to be performed and we simply can use hibernate to delete expired tickets in the cleaner. Am 26.07.2012 um 21:29 schrieb jleleu: > It could be. > > So far, in my company, we have a custom remember-me system, but the idea is > to come back to the "official" CAS remember-me. BTW, that's why I'm working > now on remember-me in CAS server / clients. > > As soon as I will have the remember-me feature fully "working", a problem > will arise : where to store all the granting tickets (and service tickets) ? > We have millions of authentications each day so I need a really strong > storage backend. > Database : why not ? but we have a somehow limited system here. > EhCache : even very simple, EhCache is not the most efficient system, in > particular if I need to use the storage on disk. > Memcached : very efficient system but not meant to be persistent. > > I'm using MongoDB for other needs and it's incredibly resistant to heavy load > : one server can handle hundreds of reads/writes per second. > So I see it as the "ultimate" ticket storage for very high traffic. > > Best regards, > Jérôme > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > robertoschw...@googlemail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
