I would say that having 2 or 3 CAS servers is really no different. -Scott
-Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Fri, Jan 9, 2009 at 9:01 AM, Andrew Feller <[email protected]> wrote: > 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 >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
