> > I'm only considering shared sessions because that seems to be what's > recommended > in the CAS wiki. >
I don't feel like the CAS wiki ever had any good high-level discussion of HA. In any case the new-ish CAS4 documentation has a HA page that spells out session affinity as a requirement for active/active deployments: http://jasig.github.io/cas/4.0.x/planning/High-Availability-Guide.html > Our networking team was unsure how sticky sessions at the load balancer > would > affect things (like applications validating STs, etc). > It tends to create hot spots on one node for a particular service, thus if you have a single that produces the heaviest load on CAS, it till tend to get pegged to a single node instead of distributing load throughout all peers in the pool. Failover characteristics are exactly the same as without session affinity. We've found that hot spots can cause trouble in fairly extreme circumstances [1], but in most cases it's a non-issue. M [1] Once a CAS-enabled timeclock application got in a redirect loop that generated millions of service tickets in a ~120m period. Our service, remarkably, held up due to a cache-backed ticket registry that simply purged old entries to hold the flood of tickets. The CPU on the node handling all that traffic went red and sent off alarms, but held up admirably. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
