tomcat dbcp _closed PoolableConnection, но в состоянии ALLOCATED

Question

Java-приложение, использующее ojdbc6.jar, tomcat 7, tomcat-dbcp-8.0.3.jar (и другие jar-файлы, которые, вероятно, не относятся к этому вопросу), JDK 7 (u51)

Мы определили, что существует утечка соединения, используя отчет v $ session, где какое-то соединение переходит в НЕАКТИВНОЕ состояние на 7+ часов. Это также подтверждается дампом потока, взятым в замороженном состоянии.

Дамп кучи (взятый в замороженном состоянии) показывает:

1. Total PoolableConnection и DefaultPooledObject равно maxTotal (ожидается для исчерпанного пула)
2. Каждое соединение связано с PooledObjectState ALLOCATED (Ожидаемый)
3. lastReturnTime = lastUserTime = lastBorrowedTime (в DefaultPooledObject), что для меня означает: THREAD-1 (хороший рабочий процесс) вернул соединение, которое было немедленно заимствовано THREAD-2 (плохой рабочий процесс с утечкой) и THREAD-2 никогда не закрывали связь, пусть болтается!

ВСЕ вышеприведенное наблюдение имеет смысл, поскольку у нас определенно есть утечка соединения и возможный исчерпанный пул

Мой вопрос: Когда я вижу подробности о PoolableConnection, он ассоциируется с логическим _closed, который имеет значение «true». Почему / Как это могло иметь "_closed = true". когда я декомпилировал tomcat-dbcp jar, я мог видеть, что каждый раз, когда _closed помечен как true, он также будет ассоциировать состояние IDLE с объектом соединения (вместо ALLOCATED).

Ищите теории о том, почему этот логический аргумент истинен.

PS: у нас есть различные идеи (например, установка logAbandoned), чтобы найти точный кусок кода, ответственный за утечку соединения, я с нетерпением жду, чтобы найти причину (или теорию) для дампа кучи для захвата этих PoolableConnection _closed = true.

Answer 1

Глядя на Исходный код DelegatingConnection , можно увидеть, что closed=true может быть установлено как результат connection.close() или в блоке finally после некоторых исключений в качестве меры безопасности.

} finally {
    closed = true;
}

Произошла утечка, соединение находится в несогласованном состоянии, поскольку не может быть закрыто и, вероятно, готово к обработке в фазе ЗАБРОШЕННОГО жизненного цикла.
Проверка пула через JMX может датьдругая перспектива.
Утечка может быть связана с неправильно обработанным исключением, которое в противном случае дало бы подсказку о плохом состоянии пула.