Как я могу узнать, почему мое приложение, использующее PostgreSQL 9, hibernate 4.3.5 и c3p0, зависает?

Question

Как я могу узнать, почему мое приложение, использующее PostgreSQL 9, hibernate 4.3.5 и c3p0, зависает?

1

Я работаю над приложением, основанным на PostgreSQL 9, hibernate 4.3.5.Final, c3p0, Tomcat 7 и JDK 7.

Вот конфигурация c3p0:

hibernate.c3p0.min_size=5
hibernate.c3p0.max_size=20
hibernate.c3p0.timeout=1800
hibernate.c3p0.max_statements=50

После нескольких часов использования приложение висит. Весь экран заблокирован, потому что казалось, что новая транзакция в базу данных не может быть открыта.

Я убил -3 в процессе tomcat 7 (развернуто одно приложение), чтобы увидеть, где все потоки заблокированы. Здесь часть результата:

"ajp-bio-8127-exec-274" daemon prio=10 tid=0x0000000001365000 nid=0x257b in Object.wait() [0x0000000045242000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1414)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:606)
    - locked <0x000000078567cb70> (a com.mchange.v2.resourcepool.BasicResourcePool)
    at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:526)
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutAndMarkConnectionInUse(C3P0PooledConnectio

Это то же самое для всех процессов запросов HTTP. Таким образом, все запросы ждут неопределенно для доступного соединения в пуле.

Мы посмотрели postgres, чтобы увидеть, что было открыто 20 соединений (20 - максимальный размер пула):

foobar=# select datname, usename, client_port, query from  pg_stat_activity where usename='foobar';
 datname | usename | client_port |  query
---------+---------+-------------+----------
 foobar  | foobar  |       52992 | ROLLBACK
 foobar  | foobar  |       52993 | ROLLBACK
 foobar  | foobar  |       52991 | ROLLBACK
 foobar  | foobar  |       52994 | ROLLBACK
 foobar  | foobar  |       52995 | ROLLBACK
 foobar  | foobar  |       36398 | ROLLBACK
 foobar  | foobar  |       36399 | ROLLBACK
 foobar  | foobar  |       36400 | ROLLBACK
 foobar  | foobar  |       51766 | ROLLBACK
 foobar  | foobar  |       56689 | ROLLBACK
 foobar  | foobar  |       56690 | ROLLBACK
 foobar  | foobar  |       39582 | ROLLBACK
 foobar  | foobar  |       39581 | ROLLBACK
 foobar  | foobar  |       39583 | ROLLBACK
 foobar  | foobar  |       39590 | ROLLBACK
 foobar  | foobar  |       39592 | ROLLBACK
 foobar  | foobar  |       39591 | ROLLBACK
 foobar  | foobar  |       41799 | ROLLBACK
 foobar  | foobar  |       36105 | ROLLBACK
 foobar  | foobar  |       36103 | ROLLBACK
(20 rows)

Итак, мы настроили журналы пулов на DEBUG, и мы можем видеть утверждения, подобные тезисам:

2014/07/09 05:24:40 DEBUG (BasicResourcePool.java:1747) trace trace com.mchange.v2.resourcepool.BasicResourcePool@12c39c9e [managed: 19, unused: 4, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@4fc04747)

Они показывают, что номер управляемой связи растет медленно до тех пор, пока не управляется: 20 и usused: 0 это конечное состояние остается стабильным и приложение заморожено, потому что все потоки ожидают, что соединение будет доступно из пула.

Это веб-приложение, и мы используем сессию в шаблоне запроса, чтобы соединение закрывалось должным образом после обработки каждого запроса (в заявлении finally). В журналах приложений нет такой вещи, как ERROR или WARN.

Как я могу знать, что я сделал неправильно?

numéro6 15 июль 2014, в 17:51

Источник

1

Не могли бы вы указать код, который вы используете для открытия и закрытия соединения? (не только отдельные строки, включите часть контекста, в котором вы их делаете)
jbx 15 июль 2014, в 23:50
2

Это GPL-лицензированное программное обеспечение, вы можете проверить исходный код , заявление try..finally в этом классе
numéro6 17 июль 2014, в 11:55
1

Ну, это не кажется try...finally , окружает все, что может пойти не так. Это только вокруг одной линии. Что если исключение произойдет в одной из строк, начиная с вызова newServiceContext() до тех пор, пока вы не try ? Может ли newServiceContext() сам newServiceContext() непроверенное исключение? Как насчет последней строки в else , почему у нее нет try ... finally окружения try ... finally ? Я бы посоветовал окружить как можно больше, а также добавить предложение catch , чтобы в случае чего-то неправильного там вы могли его зарегистрировать.
jbx 18 июль 2014, в 23:49
0

@jbx проблема здесь в том, что ничего не пошло не так. В коде над оператором try не возникает исключений, так что это не проблема. Если бы возникло исключение, я бы нашел его в журналах котов. Последняя строка ( else ) не окружена, потому что это доступ к статическому ресурсу (css ...), поэтому транзакция не требуется. Но вы правы :) Проблема в том, что вы return "redirect-to-login" оператор return "redirect-to-login" , а serviceContext создается до (а не после return ). Каждый раз, когда вызывается этот оператор return , соединение остается открытым. Исправить совершено, посмотрим. Спасибо :)
numéro6 21 июль 2014, в 10:20
1

Хорошая удача. Однако в таком случае я все же сделал бы код немного более понятным и окружил бы часть, где соединение открыто с try... finally . Это делает код более понятным, и если кто-то еще добавит одну строку кода, которая может вызвать исключение, даже непроверенную, вы все равно всегда закроете соединение ... хотите ли вы добавить catch или нет, это другая история.
jbx 21 июль 2014, в 22:55
0

Это то, что я сделал, теперь serviceContext является открытым в предложении try. Я скоро буду использовать предложение try-with-resources (см. Trunk).
numéro6 22 июль 2014, в 08:35
0

Да, именно так, если вы используете Java 1.7 или более позднюю версию, лучший способ сделать это - попробовать с ресурсами, он был специально разработан для подобных ситуаций. Я бы также немного newServiceContext() метод newServiceContext() . Существует ли риск того, что после создания контекста персистентности строка после этого вызывает исключение NullPointerException или какое-либо другое непроверенное исключение? Возможно, вы захотите отделить ресурсы, которые должны быть явно закрыты, от ресурсов, которые будут просто собирать мусор (например, объекты сеанса HTTP и т. Д.), И, возможно, связать их вместе в WaoServiceContext только когда вы try
jbx 26 июль 2014, в 12:16
3

Сейчас в производстве. Проблема исправлена. Я все еще разочарован тем, что не смог найти причину проблемы с подходящим инструментом. Все ошибки не могут быть найдены путем повторного перечитывания кода ... Спасибо jbx
numéro6 31 июль 2014, в 08:06

Показать ещё 6 комментариев

Теги:

java

postgresql

hibernate

c3p0

2 ответа

Ещё вопросы

Не могли бы вы указать код, который вы используете для открытия и закрытия соединения? (не только отдельные строки, включите часть контекста, в котором вы их делаете)
Это GPL-лицензированное программное обеспечение, вы можете проверить исходный код , заявление try..finally в этом классе
Ну, это не кажется try...finally , окружает все, что может пойти не так. Это только вокруг одной линии. Что если исключение произойдет в одной из строк, начиная с вызова newServiceContext() до тех пор, пока вы не try ? Может ли newServiceContext() сам newServiceContext() непроверенное исключение? Как насчет последней строки в else , почему у нее нет try ... finally окружения try ... finally ? Я бы посоветовал окружить как можно больше, а также добавить предложение catch , чтобы в случае чего-то неправильного там вы могли его зарегистрировать.
@jbx проблема здесь в том, что ничего не пошло не так. В коде над оператором try не возникает исключений, так что это не проблема. Если бы возникло исключение, я бы нашел его в журналах котов. Последняя строка ( else ) не окружена, потому что это доступ к статическому ресурсу (css ...), поэтому транзакция не требуется. Но вы правы :) Проблема в том, что вы return "redirect-to-login" оператор return "redirect-to-login" , а serviceContext создается до (а не после return ). Каждый раз, когда вызывается этот оператор return , соединение остается открытым. Исправить совершено, посмотрим. Спасибо :)
Хорошая удача. Однако в таком случае я все же сделал бы код немного более понятным и окружил бы часть, где соединение открыто с try... finally . Это делает код более понятным, и если кто-то еще добавит одну строку кода, которая может вызвать исключение, даже непроверенную, вы все равно всегда закроете соединение ... хотите ли вы добавить catch или нет, это другая история.
Это то, что я сделал, теперь serviceContext является открытым в предложении try. Я скоро буду использовать предложение try-with-resources (см. Trunk).
Да, именно так, если вы используете Java 1.7 или более позднюю версию, лучший способ сделать это - попробовать с ресурсами, он был специально разработан для подобных ситуаций. Я бы также немного newServiceContext() метод newServiceContext() . Существует ли риск того, что после создания контекста персистентности строка после этого вызывает исключение NullPointerException или какое-либо другое непроверенное исключение? Возможно, вы захотите отделить ресурсы, которые должны быть явно закрыты, от ресурсов, которые будут просто собирать мусор (например, объекты сеанса HTTP и т. Д.), И, возможно, связать их вместе в WaoServiceContext только когда вы try
Сейчас в производстве. Проблема исправлена. Я все еще разочарован тем, что не смог найти причину проблемы с подходящим инструментом. Все ошибки не могут быть найдены путем повторного перечитывания кода ... Спасибо jbx

jbx · Answer 1 · 2014-07-15T12-46-00.000Z

Очевидно, что эти запросы блокируются, но не освобождаются. Возможно, вы получаете какое-то исключение или что-то, чего вы не видите, потому что запрос помечен как ROLLBACK, и по какой-то причине поток висит в ожидании завершения запроса или что-то в этом роде. Не видя кода, его трудно сказать точно.

Что вы можете сделать, так это дождаться, когда это произойдет снова, а затем получите полный дамп потока. Это должно дать вам полную информацию о том, где висит нить, поэтому вы можете видеть, что ждет 20 подключений.

Вы можете использовать jstack для этого, который поставляется вместе с JDK.

Вы также можете включить JMX на Tomcat и подключиться к нему с помощью jconsole или jvisualvm, чтобы в реальном времени видеть, что делают потоки.

Как я уже сказал в вопросе, я уже знаю, где все темы висят. Все они заблокированы на com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable . Использование jconsole или jvisualvm просто даст точно такой же след.
Ну, у вас должно быть 2 вида висящих нитей. До сих пор вы показали, какие нити зависают после возникновения проблемы. Те законно висят, потому что они ждут, чтобы соединение было доступно. Другие типы потоков (у вас должно быть 20) должны висеть где-то еще ... если только у вас нет места, где вы не возвращаете соединение. Вы уверены, что все места, где вы получаете соединение, окружены блоком try ... finally , и вы закрываете соединение в finally ? Без примера кода его сложно сказать.

Vlad Mihalcea · Answer 2 · 2014-07-16T18-47-00.000Z

Похоже, ваше приложение исчерпало доступные объединенные соединения. Транзакция отмечена как откат только в случае возникновения исключения. Если вы не можете увидеть какое-либо исключение, это может быть связано с тем, что вы неправильно обрабатываете их, например, регистрируете любое исключение с порогом ERROR.

Вам также нужно проверить журнал db, возможно, вы обнаружите, что приводит к откату всех этих транзакций.

Я правильно обрабатываю исключения. Мой стиль кода подразумевает строгое правило пустого предложения catch, поэтому я думаю, что исключений не возникало никогда. Вот почему проблема такая ... раздражающая. К сожалению, у меня нет доступа к производственной платформе. Надеюсь, что администратор сможет дать мне журналы PG :-(