We've seen the same or similar behavior on our 4.0.1 instance. It doesn't happen often (maybe once every 6 months or so) but when it does happen it WILL take one of our two servers down. Were running ehcache with replication between the two servers and what we see is that when a loop occurs, the looping server stays up but the other server quickly runs out of heap space and dies.
The issue >>>SEEMS<<< for us at least to be restricted to Google services (webmail, calendar, etc.) and may have something to do with older versions of the Google apps running on mobile devices. It's hard to tell because once the issue is detected, turning on DEBUG level logging seems to reset things enough that the loop goes away and doesn't reappear for another 6-8 months. We have insufficient disk space for the systems to run at DEBUG log level all the time so we're a bit stuck trying to gather meaningful data. Dave On 12/17/15 3:33 PM, Tom Poage wrote: >>> On Dec 13, 2015, at 8:46 AM, Misagh Moayyed <[email protected]> wrote: >>> >>>> Q: Our TGTs are not replicated synchronously (every 10s), the STs are. I >>>> assume an ST entry on a CAS server contains the user principal, or we >>>> would >>>> have seen principal resolution problems much, much earlier. Correct? >>> No, TGTs do. STs represent a request from a given application/service to >>> receive the user principal from that TGT. > 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)? > > Thanks. > Tom. > -- 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/.
