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, который является "истиной". Почему / Как это могло иметь "_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 может дать другую перспективу.
Утечка может быть связана с неправильно обработанным исключением, которое в противном случае дало бы подсказку о плохом состоянии пула.