|
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. Adam Andrew Feller wrote: Please excuse the stupid questions: |
begin:vcard fn:Adam Rybicki n:Rybicki;Adam org:Unicon, Inc.;Professional Services adr:Suite 113;;3140 North Arizona Avenue;Chandler;AZ;85225;United States email;internet:[email protected] tel;work:+1-480-558-2400 tel;home:+1-310-265-8286 tel;cell:+1-310-980-2758 x-mozilla-html:FALSE url:http://www.unicon.net/ version:2.1 end:vcard
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
