Are you storing any auditing data in the database?
On Tue, May 20, 2014 at 7:03 PM, Andrew Morgan <[email protected]> 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 [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
