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/.

Reply via email to