Scott / Adam: Thanks for the replies; I am glad to see that CAS4 is aware of the issue and will attempt to alleviate it.
I think we are all in agreement that the situation varies based upon the ticket registry being used, however until CAS4 is available, I would like to come up with some kind of summarized recommendations for others who are using CAS3 at this time. We could also identify the typical issues that have occurred in using registry cleaners with the different ticket registries available, so the next generation of cleaners can learn from the problems of today. It seems the largest issues to me are that the default registry cleaner is not aware of multiple instances running and there is no mechanism for cleaners to prevent other cleaners from dealing a ticket. I believe there are 3 different scenarios to consider: 1 CAS server, 2 CAS servers, and 3+ CAS servers. BERKELEY DB TICKET REGISTRY 1 CAS server: 2 CAS servers: 3+ CAS servers: Outstanding issues with using DefaultTicketRegistryCleaner: DEFAULT TICKET REGISTRY 1 CAS server: 2 CAS servers: 3+ CAS servers: Outstanding issues with using DefaultTicketRegistryCleaner: JBOSS CACHE TICKET REGISTRY 1 CAS server: 2 CAS servers: 3+ CAS servers: Outstanding issues with using DefaultTicketRegistryCleaner: JPA TICKET REGISTRY 1 CAS server: 2 CAS servers: 3+ CAS servers: Outstanding issues with using DefaultTicketRegistryCleaner: Thanks for the feedback once again, Andy On 1/8/09 5:29 PM, "Scott Battaglia" <[email protected]> wrote: > 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? >>> 4. >>> >>> 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 list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
