Excellent analysis, thank you.
It’s worth a try, I guess, to see if adding Echo to the Cascading DAO removes the issue. I admit person-directory is mostly a mystery to most of us (and 5 does not use the Cascading DAO at all by default). Its evolution has been sinusy. --Misagh From: [email protected] [mailto:[email protected]] On Behalf Of Jeffrey Wong Sent: Friday, November 18, 2016 12:01 PM To: CAS Community <[email protected]> Subject: [cas-user] Re: After a month, no tickets created in 4.2.2? I have a lead on what the issue was related to - I had a setup with the CascadingPersonAttributeDao. Both the original production issue, and the tested behavior was observed under this attribute DAO. In testing, I have swapped out the AttributeDao with the MergingPersonAttributeDao, using a NoncollidingAttributeAddr merge strategy. I have not observed the same issue I found earlier in my tests since (across ~50k logins). While I still have not been able to re-create the original bug observed, the CascadingPersonAttributeDao seems suspect of a non-deterministic condition. I am unable to re-trigger the bug found during testing in which a single user was locked out under the new merge strategy. I'm not sure how to reproduce this issue reliably, but I can give some details about my attribute resolution if it helps: I wanted to merge the user query from the DB with a static mapping to keep track of what method they had to login (via ldap, or jdbc, or similar) to determine a user type. I was merging a NamedStubPersonAttributeDao (listed first) with a SingleRowJdbcPersonAttributeDao. The CascadingPersonAttributeDao supported the ReplacingAttributeAdder merge strategy by default (which is what I wanted), so I went with that strategy. In my own test case, the test user I was using was *not* in the jdbc database for attributes - there were no rows returned from the JDBC query, and so no attributes were added to the static map already defined. Using the CascadingPersonAttributeDao, it will initially be able to discover the principal, and log on. After a number of logins, the principal is unable to be resolved. Digging into CascadingPersonAttributeDao: It is <u>highly</u> recommended that the first DAO on the list for this class is the {@link EchoPersonAttributeDaoImpl} to ensure the seed gets placed into the general result map. Since I'm not running with an EchoPersonAttributeDaoImpl, would this perhaps be the cause of my issue? This isn't hilighted in any of the person directory readmes at all. Here's to hoping this is it. I hope this report helps you guys. -Jeff On Tuesday, July 19, 2016 at 3:09:59 PM UTC-7, Jeffrey Wong wrote: After about a month of working perfectly on 4.2.2 deployed to tomcat7, running under java8, randomly the in-memory ticketing system would not create any more tickets. Restarting the tomcat instance fixed it, but I'm wondering why CAS would randomly break on me after working so well! Using a LDAP (AD) backed user base with a mysql backed attribute DB. We have pretty minimal traffic, so I'm not sure why I am seeing issues after such a small amount of time. Despite having an <AsyncRoot level="error">, no errors have been thrown at the time of issue. Unfortunately, I've only had the org.springframework.jdbc logger set to debug, and all others at info, so I have very minimal logging around the issue. I'm noticing both the ldap auth AND the jdbc handlers returning without issues (no errors). ...But no tickets? Here's a sample of the logs: 2016-07-19 16:28:16,399 INFO [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - <LdapAuthenticationHandler successfully authenticated user1> 2016-07-19 16:28:16,400 DEBUG [org.springframework.jdbc.core.JdbcTemplate] - <Executing prepared SQL query> 2016-07-19 16:28:16,400 DEBUG [org.springframework.jdbc.core.JdbcTemplate] - <Executing prepared SQL statement[SELECT ID,username,FirstName,LastName,Email FROM User WHERE UserName = ?]> 2016-07-19 16:28:16,400 DEBUG [org.springframework.jdbc.datasource.DataSourceUtils] - <Fetching JDBC Connection from DataSource> 2016-07-19 16:28:16,401 DEBUG [org.springframework.jdbc.datasource.DataSourceUtils] - <Returning JDBC Connection to DataSource> 2016-07-19 16:28:19,015 INFO [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - <LdapAuthenticationHandler successfully authenticated user2> 2016-07-19 16:28:19,015 DEBUG [org.springframework.jdbc.core.JdbcTemplate] - <Executing prepared SQL query> 2016-07-19 16:28:19,015 DEBUG [org.springframework.jdbc.core.JdbcTemplate] - <Executing prepared SQL statement[SELECT ID,username,FirstName,LastName,Email FROM User WHERE UserName = ?]> 2016-07-19 16:28:19,015 DEBUG [org.springframework.jdbc.datasource.DataSourceUtils] - <Fetching JDBC Connection from DataSource> 2016-07-19 16:28:19,017 DEBUG [org.springframework.jdbc.datasource.DataSourceUtils] - <Returning JDBC Connection to DataSource> Immediately before this, I've seen tickets that are created (an audit log is posted that a ticket granting ticket has been created and validated, and all is good). There are no exceptions thrown between when the tickets were able to be created and when there was this bottleneck. On the front end, after the logs say 'success' without a ticket created, they are redirected to the main cas login page. Reproducing this is also difficult as it will stop intermittently, without warning. What are the best ways to debug or resolve these sorts of issues? What could be causing this issue? Thanks in advance, Jeff -- - CAS gitter chatroom: https://gitter.im/apereo/cas - CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html - CAS documentation website: https://apereo.github.io/cas - CAS project website: https://github.com/apereo/cas --- 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] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/63b2d387-f50f-429d-bf29-1411a0fb1372%40apereo.org <https://groups.google.com/a/apereo.org/d/msgid/cas-user/63b2d387-f50f-429d-bf29-1411a0fb1372%40apereo.org?utm_medium=email&utm_source=footer> . -- - CAS gitter chatroom: https://gitter.im/apereo/cas - CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html - CAS documentation website: https://apereo.github.io/cas - CAS project website: https://github.com/apereo/cas --- 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]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/024401d241d9%24c440b790%244cc226b0%24%40unicon.net.
