> 1) If a node fails, we still need to work with another one, without > authenticate users agains. Is repcached the solution for this?
Yes, but I would argue a poor solution. Memcached has a beautiful failure mode without any additional components. If an object hashes to a particular node which cannot be contacted, the memcached client we use (spymemcached) will attempt to store the key in a failover node. While I have noted some issues with the current CAS client in testing, it should be possible to provide perfectly good HA behavior for memcached without any additional complexity such as that introduced by repcache. Every distributed cache implementation I've seen (JBossCache, Infinispan, Ehcache) suffers from substantial complexity. The beauty of memcached is that you get some nice HA capabilities without the complexity if a distributed cache. > 2) I made a little test with this. I generated some STs from node 1 (ST-1, > ST-2, ...). I stopped node 1, and I generated some STs from node 2. The > nodes where named ST-1, ST-2, .... Every node names their tickets in that > way (ST-1, ST-2, ...)? Yes, every node numbers its tickets independently and begins at 1. I believe at least some of that behavior is configurable. > 3) With memcached in the middle, could I see the tickets stats in the > console (both nodes will show the same information)? There's no CAS console provided to interrogate the ticket registry, although I plan to work on such components in the near future. You can easily query memcached for statistics using its plain text command interface. For example: echo "stats" | nc cas.example.com 11211 > 4) Do I have to change something in the client when I used this solution? No. CAS clients are totally unaware of details of the server configuration such as ticket store. 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
