веб-приложение зависает в Tomcat 6.0.21 / 7.0.11 без подсказки

Question

У меня просто есть веб-приложение, которое зависает через несколько минут.По сути, это приложение для создания и предварительного просмотра форм, очень настраиваемое, и после нескольких минут интенсивного взаимодействия с пользователем приложение просто перестает работать.Это означает, что запрос выполнен и никогда не возвращает ответ.

Я "немного" потерян, так как я не нахожу никакой подсказки о зависании в журналах tomcat и журналах приложений.Сервер приложений работает так же, как я использую lambda / psi-probe, и без проблем может проверить любое другое и даже проблемное приложение (само исследование - другое веб-приложение).

Приложение использует hibernate, который работалХорошо, в течение долгого времени, и, в последнее время, для повышения производительности (Hibernate вводит много запросов, если вы работаете исключительно с ним) Я ввел нативный sql через стандартное API java.sql.Я стараюсь не смешивать оба, и они используются только в jsp, сначала получая некоторые (несколько) объектов с помощью hibernate, а затем используя некоторую логику с jdbc.Сеанс Hibernate закрывается перед использованием jdbc.

Я прочитал кое-что о проблемах подключения к базе данных (я проверял несколько раз, и сервер базы данных работает нормально), взаимоблокировках или запущенных потоках, проверенных с помощью VisualVM в VisualVM.

Итак, кто-нибудь может дать подсказку о том, как найти или поймать ловушку?Может ли что-то дать ключ к использованию VisualVM для отлова или захвата гипотетического убегающего потока или тупика?Последнее просветило бы меня, поскольку я просто вижу ожидающие и работающие потоки.

Я использую tomcat 6.0.21 (я всегда пробовал 7.0.11 с одинаковыми результатами) java 1.6 на Mac OSX и Linux (машины для разработки и подготовки к выпуску))

Любые идеи обязательно будут приветствоваться, спасибо

Вилли

Answer 1

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

Answer 2

Попробуйте запустить jconsole (если вы не можете сделать это на компьютере, на котором происходит зависание, вам потребуется включить удаленный JMX, перезапустить JVM и воспроизвести зависание), а затем перейти на вкладку Threads и нажатьОбнаружить тупик.Это может оказать некоторую помощь.

Можно использовать, как вы говорите, VisualVM или JCarder .

Редактировать

После просмотра вашего комментария можно попробовать следующее:

1. Запустите JConsole и подключитесь к зависшей виртуальной машине
2. Перейдите в MBeans → com.sun.management → HotSpotDiagnostic →Операции
3. Там будет кнопка с именем dumpHeap с двумя текстовыми полями рядом с ней.В первом текстовом поле введите уникальное имя - я использую что-то вроде моих инициалов и даты - rt20110317.Оставьте для второго текстового поля значение true.Нажмите кнопку dumpHeap.

Это позволит записать кучу в большой файл.Найдите этот файл и загрузите его в Eclipse MAT .Этот инструмент предоставляет все виды полезных фрагментов для просмотра состояния виртуальной машины.Есть даже несколько мастеров для обнаружения утечек памяти, которые также могут найти причину, по которой ваша виртуальная машина зависает, если она вызвана такими же симптомами.

Answer 3

убедитесь, что вы закрываете любые вызовы JDBC следующим образом: Справка: http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html#Preventing_dB_connection_pool_leaks

Вот пример правильно написанного кода для использования соединения БД, полученного из пула соединений:

  Connection conn = null;
  Statement stmt = null;  // Or PreparedStatement if needed
  ResultSet rs = null;
  try {
    conn = ... get connection from connection pool ...
    stmt = conn.createStatement("select ...");
    rs = stmt.executeQuery();
    ... iterate through the result set ...
    rs.close();
    rs = null;
    stmt.close();
    stmt = null;
    conn.close(); // Return to connection pool
    conn = null;  // Make sure we don't close it twice
  } catch (SQLException e) {
    ... deal with errors ...
  } finally {
    // Always make sure result sets and statements are closed,
    // and the connection is returned to the pool
    if (rs != null) {
      try { rs.close(); } catch (SQLException e) { ; }
      rs = null;
    }
    if (stmt != null) {
      try { stmt.close(); } catch (SQLException e) { ; }
      stmt = null;
    }
    if (conn != null) {
      try { conn.close(); } catch (SQLException e) { ; }
      conn = null;
    }
  }

"