CAS连接超时问题,需要刷新一次才能登陆CAS is Unavailable There was an error trying to complete your request.

最新推荐文章于 2025-08-12 19:00:00 发布

原创最新推荐文章于 2025-08-12 19:00:00 发布 · 2.7w 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#server #application #authentication #testing #mysql #exception

CAS 专栏收录该内容

5 篇文章

订阅专栏

隔夜第二天来时候发现登陆链接失效，需要刷新一次才行，

CAS is Unavailable

There was an error trying to complete your request. Please notify your support desk or try again

日志信息如下：

2012-09-07 09:11:30,235 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN

=============================================================

WHO: [username: admin]

WHAT: PreparedStatementCallback; SQL [select passwd from esb_users where enabled=1 and username = ? ]; The last packet successfully received from the server was 60,130,736 milliseconds ago. The last packet sent successfully to the server was 60,130,737 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.; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 60,130,736 milliseconds ago. The last packet sent successfully to the server was 60,130,737 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.

ACTION: TICKET_GRANTING_TICKET_NOT_CREATED

APPLICATION: CAS

WHEN: Fri Sep 07 09:11:30 GMT+08:00 2012

CLIENT IP ADDRESS: 10.1.81.226

SERVER IP ADDRESS: 10.1.83.34

可使用autoReconnect=true 参数指定，链接不失效即可。

指定如下：

<value>com.mysql.jdbc.Driver</value>

</property>

<value>jdbc:mysql://10.1.83.34:3306/icinga?autoReconnect=true</value>

</property>

<value>icinga</value>

</property>

<value>icinga</value>

</property>

</bean>

指定后还是有问题，日志报错：

严重: Servlet.service() for servlet cas threw exception
java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
   at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2503)
   at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2953)
   at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2942)
   at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3485)
   at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1960)
   at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2114)
   at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2696)
   at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2105)
   at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2264)

经过查找，似乎是mysql5已经不推荐使用autoReconnect接口了

而且如果使用proxool连接池的话，有属性用于链接前后的有效性检查。

于是，我就思考，dhcp应该也有类似的功能吧，最后加入了：

<value>SELECT 1 FROM DUAL</value>

</property>

</property>

果然好用了。

另外说说mysql的wait_timeout属性，默认是8小时，

为了测试这个问题，需要把这个值改小点，修改起来还真不好改。

set wait_timeout=5000;

发现我立马就丢失连接了，而且重新来一遍，值又回去了。

set global wait_timeout=5000;