Now that I'm a bit more accustomed to spring injection, I'm going to use the simpler merge strategies, rather than cascading for the production environments, as the code for that looks a lot less hairy.
I'll try adding Echo in a test environment, and get back to you. -Jeff On Friday, November 18, 2016 at 12:24:40 PM UTC-8, Misagh Moayyed wrote: > > 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] <javascript:> [mailto:[email protected] > <javascript:>] *On Behalf Of *Jeffrey Wong > *Sent:* Friday, November 18, 2016 12:01 PM > *To:* CAS Community <[email protected] <javascript:>> > *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] <javascript:>. > 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/70573089-e167-4164-a9b4-a3456ffd9b1c%40apereo.org.
