Мой код написан на jRuby, и я развернул его на Tomcat с помощью Warbler. Я использую Sequel для запроса базы данных MySQL. Я использую два уровня пула соединений с базой данных. Один из них — собственный пул сиквелов, другой — пул JNDI на уровне Tomcat. Строка подключения:
DB = Sequel.connect("jdbc:jndi:java:comp/env/test", :logger => $db_log, :max_connections => 10)
Эта строка подключения определена в app.rb, который загружается только при новом развертывании или перезапуске Tomcat. Это создает пул соединений Sequel, и все потоки совместно используют этот пул. Конфигурация JNDI в моем $CATALINA_OME/conf/context.xml:
<Resource
name="test"
auth="Container"
type="javax.sql.DataSource"
maxActive="10"
maxIdle="5"
maxWait="9000"
username="test_db"
password="test_db"
driverClassName="com.mysql.jdbc.Driver"
testOnBorrow="true"
testWhileIdle="true"
validationQuery="SELECT 1" testOnReturn="true"
timeBetweenEvictionRunsMillis="300000" removeAbandonedTimeout="60"
removeAbandoned="true"
logAbandoned="true"
url="jdbc:mysql://IP:3306/test"
/>
Я использую DB.disconnect для возврата соединений в пул JNDI, чтобы гарантировать, что ни один поток не использует соединение, которое использовалось ранее. Я делаю это, чтобы гарантировать ошибку wait_timeout. auto_reconnect=true не решает проблему wait_timeout должным образом. Все работало нормально, пока несколько дней назад я не начал получать такие ошибки, как:
W, [2012-07-26T05:10:30.999000 #29456] WARN -- : 134325951259087 == NativeException: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
D, [2012-07-26T05:10:31.001000 #29456] DEBUG -- : 134325951259087 == ["sun.reflect.GeneratedConstructorAccessor23:-1:in `newInstance'", "sun/reflect/DelegatingConstructorAccessorImpl.java:27:in `newInstance'", "java/lang/reflect/Constructor.java:513:in `newInstance'", "com/mysql/jdbc/Util.java:409:in `handleNewInstance'", "com/mysql/jdbc/SQLError.java:1118:in `createCommunicationsException'", "com/mysql/jdbc/MysqlIO.java:343:in `<init>'", "com/mysql/jdbc/ConnectionImpl.java:2308:in `connectOneTryOnly'", "com/mysql/jdbc/ConnectionImpl.java:2122:in `createNewIO'", "com/mysql/jdbc/ConnectionImpl.java:774:in `<init>'", "com/mysql/jdbc/JDBC4Connection.java:49:in `<init>'", "sun.reflect.GeneratedConstructorAccessor25:-1:in `newInstance'", "sun/reflect/DelegatingConstructorAccessorImpl.java:27:in `newInstance'", "java/lang/reflect/Constructor.java:513:in `newInstance'", "com/mysql/jdbc/Util.java:409:in `handleNewInstance'"
и
W, [2012-07-26T10:19:14.029000 #1572] WARN -- : 134327815053548 == NativeException: java.sql.SQLException: Connection com.mysql.jdbc.JDBC4Connection@5a0655d is closed.
D, [2012-07-26T10:19:14.030000 #1572] DEBUG -- : 134327815053548 == ["org/apache/tomcat/dbcp/dbcp/DelegatingConnection.java:398:in `checkOpen'", "org/apache/tomcat/dbcp/dbcp/DelegatingConnection.java:255:in `createStatement'", "file:/usr/local/tomcat-instance/test/webapps/service/WEB-INF/lib/santa-gems.jar!/gems/sequel-3.34.0/lib/sequel/adapters/jdbc.rb:523:in `statement'", "file:/usr/local/tomcat-instance/test/webapps/service/WEB-INF/lib/santa-gems.jar!/gems/sequel-3.34.0/lib/sequel/adapters/jdbc.rb:233:in `execute'", "file:/usr/local/tomcat-instance/test/webapps/service/WEB-INF/lib/santa-gems.jar!/gems/sequel-3.34.0/lib/sequel/connection_pool/threaded.rb:88:in `hold'", "file:/usr/local/tomcat-instance/test/webapps/service/WEB-INF/lib/santa-gems.jar!/gems/sequel-3.34.0/lib/sequel/database/connecting.rb:234:in `synchronize'", "file:/usr/local/tomcat-instance/testv/webapps/service/WEB-INF/lib/santa-gems.jar!/gems/sequel-3.34.0/lib/sequel/adapters/jdbc.rb:232:in `execute'", "file:/usr/local/tomcat-instance/test/webapps/service/WEB-INF/lib/santa-gems.jar!/gems/sequel-3.34.0/lib/sequel/dataset/actions.rb:744:in `execute'", "file:/usr/local/tomcat-instance/test/webapps/service/WEB-INF/l
Эти ошибки происходят слишком часто, чтобы их можно было игнорировать.
Единственное изменение, которое произошло, — это хост базы данных, но я убедился, что переменные тайм-аута остались прежними. Значения:
interactive_timeout=300
connect_timeout=300
wait_timeout=10
Есть ли что-то еще, что могло бы создать разницу?
