Sounds interesting! Keep us in the loop on what you discover.
On Tue, Aug 16, 2011 at 2:43 PM, Eric Pierce <[email protected]> wrote: > Has anyone else looked at couchbase/membase server ( > http://www.couchbase.org/get/couchbase/current)? I moved my test and dev > instances of CAS to it from memcached this weekend and it looks like a great > replacement for repcache: > * Uses the standard Memcache protocol - MemCacheTicketRegistry works > without modification > * Supports clusters with more than 2 nodes > * Multiple data 'buckets' that allow you to partition your server > and separate applications > * Apache 2 licensed community edition with a commercial edition with > support contracts available > * In use at some really high-traffic sites - Zynga uses it for Farmville, > Mafia wars, etc (I'm trying not to hold that against it) > * Nice web-based monitoring/admin console for keeping tabs on the health of > the cluster > > There are also membase-specific enhancements in the new version of the > spymemcached client. I'm going to look at updating MemCacheTicketRegistry > to take advantage of the new version > > -Eric > > On Tue, Aug 16, 2011 at 11:04 AM, Kirk, Matt <[email protected]> wrote: > >> Thanks for all the feedback. >> >> We're opting for the distributed Ehcache ticket registry over a database >> persistent registry across a CAS Cluster as we feel that if a node goes >> down, then the ticket replication will allow seamless access to services and >> therefore the DB is not required (and would itself be a single point of >> failure unless replicated in some fashion). The failed node can then be >> re-started and rejoin the cluster and be re-populated with the current >> tickets via the distributed Ehcache. >> >> If the entire cluster were to go down it would require users to >> re-authenticate but we consider this a (hopefully) rare and fatal system >> failure so forcing users to re-authenticate after system re-start is >> acceptable. >> >> This approach removes the need for a database and all the cost / admin etc >> that goes with it. >> >> Do you think is is a reasonable solution? Have I missed something which >> may change my thoughts? >> >> Thanks, >> Matt >> >> >> ------------------------------ >> *From:* Scott Battaglia [[email protected]] >> *Sent:* 16 August 2011 14:55 >> >> *To:* [email protected] >> *Subject:* Re: [cas-user] CAS in load balanced environment >> >> On Tue, Aug 16, 2011 at 9:47 AM, Marvin Addison < >> [email protected]> wrote: >> >>> > what is the Memcache solution and do you have a setup guide? >>> >>> See https://wiki.jasig.org/display/CASUM/MemcacheTicketRegistry. I'll >>> discuss briefly what's _not_ in the manual. I think there's some >>> misinformation in the community, borne out in list discussions and >>> other venues, about the need for the repcache patches to memcached for >>> clustering. I think repcache is absolutely unnecessary based on the >>> failure mode of memcached. Consider a memcached cluster of 3 nodes, >>> all noted in the CAS configuration. The Java memcached client will >>> calculate a key and store it on one node. If that node goes down, the >>> client will attempt to retrieve the key from the dead node and fail, >>> returning an empty value. That will appear to CAS and ultimately the >>> user that he or she is unauthenticated and will simply need to >>> reauthenticate. Upon reauthentication the client will know that there >>> are only two nodes remaining, and calculate a new key that will be >>> stored on one of the two available nodes and proceed as normal. That >>> is a _very_ graceful failure mode in my opinion, and there's no need >>> for anything additional like repcached. >>> >> >> It really depends on your needs. You may feel that its acceptable to >> force them to log back in if a node goes down, others may not. This is why >> we have a number of these backing mechanisms, you find the one that matches >> your expertise and meets your availability requirements. >> >> However, as you note, using repcached is optional, and just provides an >> extra level of redundancy if you want to apply the patch. (we did at >> Rutgers) >> >> Cheers, >> Scott >> >> >> >>> >>> > Is one solution favourable over another? >>> >>> Most folks choose based on experience with a particular technology. >>> We use JpaTicketRegistry on PostgreSQL in production, but I'd be happy >>> to switch to memcached if needed. I personally think Terracotta, >>> JBossCache, and Infinispan are interesting technologies that are >>> overkill for CAS. The complexity is not worth the benefits. That is >>> absolutely a personal opinion and lots of folks would disagree. >>> >>> M >>> >>> -- >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>> >>> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> >> Information in this email including any attachments may be privileged, >> confidential and is intended exclusively for the addressee. The views >> expressed may not be official policy, but the personal views of the >> originator. If you have received it in error, please notify the sender by >> return e-mail and delete it from your system. You should not reproduce, >> distribute, store, retransmit, use or disclose its contents to anyone. >> Please note we reserve the right to monitor all e-mail communication through >> our internal and external networks. SKY and the SKY marks are trade marks of >> British Sky Broadcasting Group plc and are used under licence. British Sky >> Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited >> (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. >> 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are >> direct or indirect subsidiaries of British Sky Broadcasting Group plc >> (Registration No. 2247735). All of the companies mentioned in this paragraph >> are incorporated in England and Wales and share the same registered office >> at Grant Way, Isleworth, Middlesex TW7 5QD. >> >> -- >> >> You are currently subscribed to [email protected] as: [email protected] >> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> > > > -- > Eric Pierce > Identity Management Architect > Information Technology > University of South Florida > (813) 974-8868 -- [email protected] > > -- > > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
