Есть старая и до конца нерешенная проблема. На сервере (2хXeon) работает большое приложение, использующее EJB+Struts. В качестве контейнера - JBoss, ось - Debian Sarge. Так вот, через определенное время (иногда минуты, иногда многие часы) JVM падает без объяснения каких-либо причин. Закономерностей падения выявить не удалось. Пробовали использовать JBoss версий 3.0.8, 3.2.1, 3.2.6, 4.0.1, Sun JRE версий 1.4.0, 1.4.1, 1.4.2 разных модификаций и в разных комбинациях. В любом случае рано или поздно заканчивается все крушением JVM. Пробовали использовать рекомендуемую JBoss JRockit, которая не падает, зато вешается намертво с той же переодичностью. Есть решение проблемы - запускать JVM с ключами -Xint и -Xrs (отключение Hotspot и сокращение использования сигналов ОС соответственно). Тогда все работает стабильно, но при этом сильно страдает производительность. В этой связи два вопроса:

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

Не сталкивался.

Падает именно JBoss ? Или вообще JVM падает иногда ? Может тогда попробовать из под дебагера JVM запустить ?

Может что-то с аппаратными проблемами связано ? Или сам Линух гадит что-то ?

Вообще конечно противная проблема. Сочуствую.

Железо отпадает - одно и тоже на двух серверах, правда оба двухпроцессорные. Падает именно JVM. Из под дебаггера по-моему смысла запускать нет - падает все в неопределенные моменты времени и никаких исключений не кидает, хотя возможно есть способы отловить ошибку, которые я не знаю. Проблема в Линухе или в JDK для Линуха, в винде всего этого не наблюдается. Хотя за то время, пока существует проблема (примерно года два), и ядро Линуха поменялось и софт. В принципе-то о решении я уже сказал, но вот производительность терять не хочется - она падает в разы.

Цитата(tux @ 4.8.2005, 13:08)

Проблема в Линухе или в JDK для Линуха, в винде всего этого не наблюдается.

К сожалению помочь ничем не могу - не сталкивался
А за информацию - спасибо. Надо иметь в виду такую ситуацию. Если вдруг найдете причину - поделись пожалуйста. Ну а если и рецепт устранения получится - тогда ОГРОМНОЕ СПАСИБО скажем.

1. На однопроцессорном линуксовом сервере у меня похожая проблема прошла после установки другого линукса.

2. В коде commons-collections (FastHashMap) читал, что :
<p><strong>NOTE</strong>: <i>This class is not cross-platform.
* Using it may cause unexpected failures on some architectures.</i>
* It suffers from the same problems as the double-checked locking idiom.
* In particular, the instruction that clones the internal collection and the
* instruction that sets the internal reference to the clone can be executed
* or perceived out-of-order. This means that any read operation might fail
* unexpectedly, as it may be reading the state of the internal collection
* before the internal collection is fully formed.
* For more information on the double-checked locking idiom, see the
* <a href="http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html">
* Double-Checked Locking Idiom Is Broken Declaration</a>.</p>

У меня был случай, когда на многопроцессорной машине под линуксом JVM падала по этой причине ...

Может, где-то в коде есть похожие на описанные фрагменты?

ЗЫ. Обычно JVM, падая, все же пишет нечто о причине падения в log файлы. По ним тоже можно попытаться

ЗЗЫ А под виндами тоже на 2=х процессорной машине пробовали?

Идея pvo о "not cross-platform" классе натолкнула на мысль, что причиной падения JVM может быть нативный код. Единственное место, где есть нативный код - Legacy CLI-based JDBC driver для DB2 (db2java.zip), использующий платформозависимые клиентские библиотеки. Поменял его на ibm-овский же Universal JDBC driver (db2jcc.jar, pure Java), сутки JBoss стоит как влитой. Хотя возможно еще не вечер, будем наблюдать. Обо всех результатах проинформирую.
В общем, большое спасибо pvo за идею. Был бы зарегистрирован и была бы у меня возможность, добавил бы "+".

Ну что же, можно видимо констатировать, что проблема решена успешно. Уже неделю все работает стабильно, видимо причина была все-таки в Legacy CLI-based JDBC driver. Причем его нестабильная работа наблюдается только в многопроцесорной среде. Большое спасибо AntonSaburov и pvo за участие и идею.

Это сообщение отредактировал(а) tux - 11.8.2005, 13:20

Та же проблемма - думаю что сам бы до решения копал долго
Есть WAS 5.0 на котором запущено приложение, работающее с DB2. Сервисы позволяют просматривать таблицы и вносить в них изменения – использую COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource
Так же в приложении запускается таймерная задача которая раз в 2 минуты анализирует данные в специальной таблице – и если выполняется определённое условие, то таймер вызывает методы которые вносят изменения в базу. Таймер использует свой JDBC драйвер с перманентно созданным соединением
COM.ibm.db2.jdbc.net.DB2Driver;
По не понятной мне причине сервер отработав некоторое время – падает. Причём никаких сообщений в логах не остаётся.
Наблюдается ещё один интересный эффект – если запустить приложение на сервере (таймер стартует автоматически при запуске), но не обращаться к нему при помощи браузера (не инициализировать других сервлетов), то таймерная задача работает, вносит изменения – и с сервером всё в порядке. Если идёт обращение к приложению от пользователя то сервер через некоторое время падает.
Может кто подскажет в чём проблема?
З.Ы.
Пускал приложение и под WSAD 5.0.1 на тестовом сервере – тот же эффект
----
З.З.Ы
Отлавил вот такую вот штуку за пару минут до падения сервера
java.lang.ClassNotFoundException com.ibm.ws.classloader.CompoundClassLoader.loadClass 248
Спасибо pvo за этот линк!

Рады, что наш форум помог - заходите почаще.

ИТОГО:
Всё же решил отпиваться о решении проблемы – было замечено, что подобная ситуация возникает периодически.

Почитав доступный онлайн материал натолкнулся на мысль, что причиной падения JVM может быть нативный код. Единственное место, где есть нативный код - Legacy CLI-based JDBC driver для DB2 (db2java.zip), использующий платформозависимые клиентские библиотеки. (спасибо Денису Литвинову)

Поменял драйвер а ibm-овский Universal JDBC driver (db2jcc.jar, pure Java).

Запустил консольное приложение для проверки работоспособности драйвера, тут же словил не большую проблему: db2jcc.jar возник для DB2 8 – а у меня версия 7.1 и пакет с SQL запросом не распознаётся. Проблема лечится достаточно просто: в db2jcc.jar есть класс DB2Binder который позволяет выполнить bind требуемых пакетов на нужную вам БД. Запускается из командной строки:
-url jdbc:db2://host:port/DB –user userName -password userPassword

После чего с вышеуказанным драйвером можно работать в 7.1

При работе с драйвером в WEB-приложениях сам jar нужно прописать в конфигурацию сервера ws.ext.dits и class path – обязательно и туда и туда. Иначе возникает ошибка при использовании пула.

В итоге первоначальная проблема была разрешена – сервер работает, приложение тоже.