> I used some iptables rules to simulate the MySQL server being unavailable. > The following log entries appeared: > > 2013-01-23 16:09:34,309 ERROR > [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] - The last packet > successfully received from the server was 774,962,088 milliseconds ago. > The last packet sent successfully to the server was 774,962,089 > milliseconds ago. is longer than the server configured value of > 'wait_timeout'. You should consider either expiring and/or testing > connection validity before use in your application, increasing the server > configured values for client timeouts, or using the Connector/J connection > property 'autoReconnect=true' to avoid this problem. > > 2013-01-23 16:16:40,322 ERROR > [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] - Could not create > connection to database server. Attempted reconnect 3 times. Giving up.
Are those the only errors? What exactly was the behavior of CAS from the perspective of an end user? Did it emit a stack trace or simply time out on a GET to /login? In any case I'm fairly surprised by this behavior. > Is there something wrong with my configuration? Not that I can see. > Is the wiki note about availability wrong? No. We've had database outages in the past and CAS has remained responsive. That jibes with the design and the wiki comment. Here's a theory: you've set up a firewall to swallow SYN (fairly typical firewall rule), which some component from database driver to c3p0 doesn't like it. In practice it's far more common to receive a RST packet when you attempt to communicate over a broken channel. If you've blackholed the MySQL port such that you get _nothing_ back from the other end, it's possible you're running into a weird edge case that's not handled well. M -- 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
