Some followup: > On Dec 13, 2015, at 8:46 AM, Misagh Moayyed <[email protected]> wrote: > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of Tom >> Poage >> Sent: Friday, December 11, 2015 10:48 AM >> To: CAS Community <[email protected]> >> Subject: [cas-user] CAS looping >> >> 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. > > DEBUG-level logs for both CAS and Ehcache might explain this a bit more, if > you can catch this in the act. Lopping behavior generally indicates an ST > validation problem, for which one possible cause might be cache eviction > policy. If the cache is not cleaning up after itself, it will continue to > grow which at some point this will trigger the JVM to stop the world, clean > dead objects in cache/memory and reclaim lost space. This will bring the > system down to a halt until it recovers itself. This is just my guess, based > on feedback I have heard from other folks running Ehcache.
Here's observed behavior for this case (mod_auth_cas): > 169.237.111.XXX - [11/Dec/2015:08:56:03] 122 "GET /protected/path > HTTP/1.1" 302 > 169.237.111.XXX userxxx [11/Dec/2015:08:56:12] 93485 "GET > /protected/path?ticket=ST-... HTTP/1.1" 302 > 169.237.111.XXX - [11/Dec/2015:08:56:13] 147 "GET /protected/path > HTTP/1.1" 302 > 169.237.111.XXX userxxx [11/Dec/2015:08:56:13] 2472638 "GET > /protected/path?ticket=ST-... HTTP/1.1" 302 > 169.237.111.XXX - [11/Dec/2015:08:56:15] 185 "GET /protected/path > HTTP/1.1" 302 > 169.237.111.XXX userxxx [11/Dec/2015:08:56:15] 88188 "GET > /protected/path?ticket=ST-... HTTP/1.1" 302 > 169.237.111.XXX - [11/Dec/2015:08:56:15] 177 "GET /protected/path > HTTP/1.1" 302 > 169.237.111.XXX userxxx [11/Dec/2015:08:56:15] 86778 "GET > /protected/path?ticket=ST-... HTTP/1.1" 302 > 169.237.111.XXX - [11/Dec/2015:08:56:15] 204 "GET /protected/path > HTTP/1.1" 302 > 169.237.111.XXX userxxx [11/Dec/2015:08:56:15] 96232 "GET > /protected/path?ticket=ST-... HTTP/1.1" 302 > 169.237.111.XXX - [11/Dec/2015:08:56:16] 169 "GET /protected/path > HTTP/1.1" 302 > 169.237.111.XXX userxxx [11/Dec/2015:08:56:16] 91965 "GET > /protected/path?ticket=ST-... HTTP/1.1" 302 > 169.237.111.XXX - [11/Dec/2015:08:56:16] 231 "GET /protected/path > HTTP/1.1" 302 > 169.237.111.XXX userxxx [11/Dec/2015:08:56:16] 99874 "GET > /protected/path?ticket=ST-... HTTP/1.1" 302 > 169.237.111.XXX - [11/Dec/2015:08:56:16] 239 "GET /protected/path > HTTP/1.1" 302 > 169.237.111.XXX userxxx [11/Dec/2015:08:56:16] 87969 "GET > /protected/path?ticket=ST-... HTTP/1.1" 302 > 169.237.111.XXX - [11/Dec/2015:08:56:16] 201 "GET /protected/path > HTTP/1.1" 302 > 169.237.111.XXX userxxx [11/Dec/2015:08:56:16] 88978 "GET > /protected/path?ticket=ST-... HTTP/1.1" 302 Looks like mod_auth_cas is resolving the user principal, but then it's not getting into the application. The loop continues for about 25 seconds. To be complete, the setup is uses AJP to proxy to a servlet running under Tomcat. This setup has worked very well for several years. It seems in this case the principal is (1) not being passed into AJP (mod_proxy_ajp) my mod_auth_cas, (2) not being picked up by the Tomcat AJP connector and/or not being set in the environment, or (3) the servlet is somehow missing picking up the principal with getRemoteUser(). If it matters, the webapp is Shibboleth 2.x IdP. The numbers between the timestamp and the GETs are response time (microseconds); we were having some CAS server problems (load?) around that time frame. Anyhow, seems the problem in this case doesn't seem to be CAS. I'd be curious to know if this type of behavior has been observed elsewhere (Apache httpd 2.2, Tomcat6, Java 7, Oracle [aka RedHat] Linux 6) while we try to carve off resources to upgrade to 4.x. 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/.
