If the only thing reading from a database is the services registry, it doesn't even do that frequently (it actually keeps a cached copy in memory) so I'm not sure where else database failures can be coming in during a login.
On Wed, May 21, 2014 at 11:43 AM, Andrew Morgan <mor...@orst.edu> wrote: > Heh, that's exactly what Marvin asked me last year. :) > > No, Inspektr is logging to an audit file. To make doubly sure, I even > turned off auditing by commenting out the auditTrailManager bean and > removing the auditTrailContext.xml file. > > Thanks, > Andy > > > On Tue, 20 May 2014, Scott Battaglia wrote: > > Are you storing any auditing data in the database? >> >> >> On Tue, May 20, 2014 at 7:03 PM, Andrew Morgan <mor...@orst.edu> wrote: >> >> I'm reviving my old thread from last year because I need to perform some >>> maintenance on MySQL and we cannot have our CAS instance be unavailable >>> for the duration of the maintenance. >>> >>> I'm running CAS v3.5.2 with my ticket registry stored in memcache and my >>> services registry stored in MySQL. When MySQL is down, submitting the >>> CAS >>> login form returns a "CAS is unavailable" error page from the CAS server. >>> I have attached the stack trace that is dumped into catalina.out when >>> this >>> error occurs. >>> >>> I am simulating a MySQL outage with the following iptables rule: >>> >>> iptables -A INPUT -p tcp -i eth0 --dport 3306 -s 128.193.x.y -j REJECT >>> --reject-with tcp-reset >>> >>> A packet capture of the traffic to the MySQL server shows that during a >>> successful authentication (MySQL up), the following SQL commands are >>> issued: >>> >>> SET autocommit=0 >>> commit >>> SET autocommit=1 >>> SET autocommit=0 >>> commit >>> SET autocommit=1 >>> >>> When MySQL is down, the first "SET autocommit=0" is sent, which then >>> causes the "CAS is unavailable" error. >>> >>> The stack trace indicates that some Spring AOP proxy is intercepting the >>> call to createTicketGrantingTicket(). I see that >>> createTicketGrantingTicket() has an @Transactional annotation applied to >>> it. Could this be causing the spurious calls to autocommit and commit? >>> >>> I know a few people have reported this same issue, and other people have >>> reported things working fine while MySQL is down. >>> >>> Is there any additional logging or testing I can do to narrow this down? >>> >>> Thanks, >>> Andy >>> -- >>> You are currently subscribed to cas-user@lists.jasig.org as: >>> scott.battag...@gmail.com >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>> >>> >> -- >> You are currently subscribed to cas-user@lists.jasig.org as: >> mor...@orst.edu >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> > > -- > You are currently subscribed to cas-user@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
