On Thu, Jan 8, 2009 at 6:18 PM, Adam Rybicki <[email protected]> wrote:
> Andrew, > > Let me take a stab at answering your questions, even though I may not be > the most qualified to answer them. I have had exposure to some of the same > issues that have prompted your questions, so let me at least state my > opinions here. > > To answer your first question directly, I could just say that CAS itself > would not mind having multiple registry cleaners. It's probably better to > ask what would these multiple registry cleaners do to each other. ;-) The > reason I say this is because the TicketRegistry implementations are > specifically designed for access from multiple threads, so they are unlikely > to get damaged by multiple cleaners. Undamaged TicketRegistry probably > means happy CAS. > > There is one very good reason to run multiple registry cleaners in a > cluster. If you had one cleaner and the cluster member running the cleaner > were to fail, you would end up with no cleaner until that cluster member was > restarted. On restart that registry cleaner should pick up where it left > off, and things would be OK. If you wanted to run multiple cleaners to > avoid that problem, you would have to use a cleaner that's cluster-aware. > Well, that's actually more complicated. Let me elaborate... > > Registry cleaner has to be compatible with the type of TicketRegistry you > are using. DefaultTicketRegistryCleaner will work fine with > DefaultTicketRegistry or JBossTicketRegistry, although its performance with > JBossTicketRegistry may need to be validated. No existing cleaner is > compatible with MemCacheTicketRegistry because there is no way to enumerate > all tickets in that registry implementation, but memcached has its own > methods of expiring old entries. In my opinion, a new cleaner could be > written to clean JpaTicketRegistry without deadlocking the database. > DefaultTicketRegistry doesn't technically deadlock the database to my > knowledge, but it locks it out for too long. > > In my opinion, every implementation of TicketRegistry should be accompanied > with a compatible cleaner implementation or at least documentation of which > existing cleaner should be used with it. That's as long as the > TicketRegistry interface remains unchanged. > > Did you ever wonder why there are so many garbage collectors in Java and > that there is no "one size fits all?" Well, this is a similar issue. > I think Adam summarized everything pretty well :-). I will add that in CAS4 we've taken notice of this issue and each TicketRegistry (in CAS4 called SessionStorage) will be responsible for its own cleaning. The public API has a method called prune that can be scheduled to be called and can coordinate itself with other versions of itself if necessary (that's up to the SessionStorage to do). Any further feedback or comments is appreciated. -Scott > > > Adam > > Andrew Feller wrote: > > Please excuse the stupid questions: > > > 1. How does CAS react whenever there are multiple registry cleaners > within a CAS cluster? > 2. Is it recommended to run multiple registry cleaners within a CAS > cluster? > 3. If it is not recommended, then what is the recommended manner for > configuring the registry cleaner? > > > I am well aware that this will vary depending on the ticket registry being > used; MemcachedTicketRegistry doesn't use a registry cleaner, > JpaTicketRegistry can bring down the server depending on number of entries, > etc. I am assuming that even with the default ticket registry and registry > cleaner there are going to be issues. > > I hope to add this to the JA-SIG wiki in hopes this helps anyone else, so > please contribute as you can. > > Thanks, > Andrew > -- > Andrew Feller, Analyst > LSU University Information Services > 200 Frey Computing Services Center > Baton Rouge, LA 70803 > Office: 225.578.3737 > Fax: 225.578.6400 > > ------------------------------ > > _______________________________________________ > Yale CAS mailing > [email protected]http://tp.its.yale.edu/mailman/listinfo/cas > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
