We had to switch load balancer redirects to our CAS (3.5.2.1) servers from round robin to primary and backup because validation requests were coming in faster than ehcache could replicate.
Ray On 2015-12-18 08:13, Tom Poage wrote: > That's good to know. If I recall correctly, prior sample configurations of > CAS 3.x--at least with Ehcache--had TGTs configured to replicate > asynchronously and STs synchronously (interpreted as non-real time and real > time, respectively). > > So if I understand correctly, *both* TGT and ST cache entries need to be > available to the local server instance at the time of ST validation. The > above configuration then represents a race condition on "first" login > (absence of valid TGT available to the validating server). > > Certainly, this doesn't hold for cache technologies where the ST validating > server "discovers" the peer node holding the valid TGT. I don't recall if > Ehcache is the only supported cache using full N-way replication; other N-way > caches would seem to have similar limitations. > > Finally, I'm surprised we didn't see this much earlier in our load testing or > in production systems once deployed. Perhaps our load testing scenarios were > flawed; perhaps the looping issue has been there all along and we didn't > notice until the cluster was under duress. Given our usual TGT creation rate, > I'm surprised we don't see a higher baseline rate of looping in the logs than > we do now (looking specifically for it, maybe a handful an hour). > > Tom. > >> On Dec 17, 2015, at 10:40 PM, Misagh Moayyed <[email protected]> wrote: >> >>> Does this mean TGTs must/should be replicated synchronously (in order to >>> have a local cache entry against which to resolve an ST to a principal)? >> That depends on your load. If the time it takes for an ST validation call to >> reach a node is shorter than the time it takes for a TGT to reach that node >> (from the one that created it originally), then yes you want to replicate >> TGTs synchronously. The best way you can tell what that threshold could be >> is to run stress tests against your CAS deployment, put it under extreme >> load and see where the failures begin. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
