Моя проблема:
У меня есть веб-приложение Java, которое использует простой JDBC для подключения к mysql базу данных через сервер приложений Glassfish.
Я использовал пул соединений на сервере Glassfish со следующими конфигурациями:
Начальный размер пула: 25
Максимум Размер пула: 100
Количество изменений размера пула: 2
Тайм-аут простоя: 300 секунд
Максимальное время ожидания: 60 000 миллисекунд
Приложение было развернуто в течение последних 3 месяцев и работало безупречно.
Но за последние 2 дня при входе в систему возникает следующая ошибка.
Частичная трассировка стека
Код: Выделить всё
com.mysql.jdbc.exceptions.MySQLNonTransientConnectionException: No operations allowed after connection closed.Connection was implicitly closed due to underlying exception/error:
** BEGIN NESTED EXCEPTION **
com.mysql.jdbc.CommunicationsException
MESSAGE: Communications link failure due to underlying exception:
** BEGIN NESTED EXCEPTION **
java.io.EOFException
MESSAGE: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
STACKTRACE:
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:1997)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2411)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2916)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1631)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1723)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3256)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1313)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1448)
............
............
my application traces....
РЕДАКТИРОВАТЬ: Проблема сохраняется даже после перезапуска сервера. По мнению администратора базы данных, две важные конфигурации сервера MySQL:
wait_timeout: 1800 секунд
connect_timeout: 10 секунд.
ПРИМЕЧАНИЕ. Другие приложения, развернутые на том же сервере, подключающиеся к той же базе данных и использующие разные пулы, работают без сбоев.
EDIT-2: Прочитав много информации и ожидая какого-то положительного результата, я внес эти изменения в свой пул соединений.
Максимальное время ожидания: 0 (ранее оно составляло 60 секунд)
Проверка соединения: Требуется
Метод проверки: таблица
Имя таблицы: Демо
< strong>Проверка максимум один раз: 40 секунд
Попытки повторения создания: 1
Интервалы повтора: 5 секунд
Максимальное использование соединения: 5
И это сработало, поскольку приложение работало непрерывно в течение 3 дней. Но из этого я получил очень странный и интересный результат. При мониторинге пула соединений я обнаружил следующие цифры:
NumConnAcquired: 44919 Count
NumConnReleased: 44919 Количество
NumConnCreated: 9748 Количество
NumConnDestroyed: 9793 Количество
NumConnFailedValidation: 70 Count
NumConnFree: 161 Count
NumConnUsed: - 136 Count
Как NumConnFree может стать 161, если у меня максимальный размер пула = 100 ?
Как NumConnUsed может стать -136, отрицательным числом ?
Как может NumConnDestroyed > NumConnCreated ?
Подробнее здесь: https://stackoverflow.com/questions/139 ... ver-expect