В логах томкета увидел вот такое:


такое написало после удаления второй страны, потом метод jsf бина getAllCountry уже не смог прочитать страны:


Это не похоже на ошибку ?)

Выяснил что приложение ложиться из за:


Смотрел через профайлер, когда доставал список стран было видно что очень сильно скакнула память ... памяти выделил 512 метров, каким образом так быстро память улетает ? Что с этим делать?

permGen используется для кэширования классов (в числе прочего) и в если ошибки будут продолжатся и далее, то нужно посмотреть где текут класслоадеры (java.lang.Classloader и его наследники)

для этого есть утилитка jmap, запускай её с ключом -permstat и смотри на результат. На винде она не работает с этим ключом к сож.

jmap -permstat <pid>

Добавлено через 5 минут и 23 секунды
для винды, чтото вроде http://www.yourkit.com/docs/kb/class_loaders.jsp о

Установил YourKit, попытался разобраться .... но очень много показателей и просто напросто запутался. Можете подсказать куда конкретно посмотреть ? Или может быть просто увеличить permsize ? 

нашел во вкладке Class List:


есть еще один класс, объектов которого 51 ... но он не мой, он находится в пакете com.sun.org...

ну и есть 118 799 - java.lang.String  и примерно столько же char[]

p.s. Как часто вообще сталкиваются с такими проблемами ? Не у одного знакомого такого не было...

Это сообщение отредактировал(а) 4epT - 20.4.2011, 22:42

в моей практике было пару раз. Причиной может быть количество классов в аппликухе (включая библиотеки, конечно) требующее больший permgen чем выделяется по умолчанию, или, "ClassLoader leak" - когда классы загружаюся в новый класслоадер снова и снова, и ссылка на класслоадер остаётся. 

первое просто требует увеличения permgen, второе -баг в аппликухе и его надо найти и исправить.

Добавлено через 2 минуты и 23 секунды
Если после увеличения до 512м у тебя ошибки прекратяться, то всё в порядке. Если будут продолжать лезть - найди наиболее повторяющийся класслоадер (г. типа org.spring org.hibernate ) и следи, не растёт ли их число .

Не подскажешь как правильно увеличить permgen ?  )

я через IDE (netbeans) полез в настройки сервера и прописал там параметр: -XX:MaxPermSize=512m

catalina.bat декларирует несколько параметеров; твой - JAVA_OPTS

нужно установить присвоить переменной окружения ( Environmеnt Variable ) значиение  -XX:MaxPermSize=512m 

если запускаешь из коммандной строки сделай 

set JAVA_OPTS=-XX:MaxPermSize=512M
catalina.bat start


или установи её глобально, такоже как устанавливают JAVA_HOME, ANT_HOME, ORACLE_HOME и т.д.

Ну и конечно убедись что она действительно встала с помощью jvisualvm или jconsole

dobrolub, увеличение permgen результата не дало ( какие самые распространенные баги в "аппликухе" ? Как выяснить где я напорол ? 

Ну вот перезагрузка веб-аппликухи такой эффект может дать. В томкат 7 есть даже такая фишка - протекция против permgen leak. http://wiki.apache.org/tomcat/MemoryLeakProtection

Я думаю первый шаг - убедиться что ты на томкат 7, а потом анализировать дерево классов, смотреть что держит лоадеры которые растут в  числе. Ешё погугли на предмет permgen и библиотек которые в твоей аппликухе крутятся.

скажите пожалуйста, а может ли быть проблема в неправильной конфигурации Spring / Hibernate ?

P.s. просто в плане архитектуры у меня сомнения в том что я  где то напорол ... так как весь дао списан с работы.  Единственное что сам писал так это файлы конфига + вместо Struts подключил JSF ...

Это сообщение отредактировал(а) 4epT - 21.4.2011, 17:24

Выяснил что метод getAllCountry за один сабмит вызывается три раза Оо.

вот код страницы:



А вот managed jsf bean:


Как видно, я по "сабмиту" вызываю метод getAllCountry и потом перерисовываю панель. Каким образом метод вызывается 3 раза ?

2 раза вызывается - при нажатии на кнопку и один раз после удаления.
 

Это сообщение отредактировал(а) 4epT - 21.4.2011, 23:25

4epT, сам сейчас только вникаю в тонкости JSF, но в общем троекратный вызов метода связан с жизненным циклом запроса.

Как только твой запрос пришёл на сервер, JSF пытается восстановить дерево страницы и провалидировать значения. После обработки он обновляет дерево страницы - и тоже запрашивает данные со всех бинов - глянь на код своей страницы. 

У тебя там есть запись 



Соответственно, при восстановлении дерева страницы, JSF должен знать какая инфа может содержаться в данном компоненте и перед рендерингом, при обновлении дерева ему нужно получить актуальную инфу для селекта + в процессе валидации скорее всего дёргает проперти данного бина (не спрашивай почему, для меня пока это тоже тёмный лес).

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

Вообще работая с БД в JSF без кеша лучше не жить - жрёт память как бегемот и тупит как ленивец.

Добавлено @ 11:09
Попробуй в самом деле с хиберовскими кешами поиграться - может поможет?

Добавлено @ 11:11
Особое внимание удели кешу второго уровня. Он там по умолчанию отключен.

Это сообщение отредактировал(а) kaa - 26.4.2011, 11:11

Спасибо за ответ =) Я включил в настройках хибера использовать кеш второго уровня - это достаточно ? или лучше использовать специальные либы для кеша ?

Ну и на сколько я понял трехкратный вызов метода никак не исправить ?)

P.s. зависание больше не происходит ... исправил в baseDaoImpl метод - list. Сделал его @Transactional. 

Привет!

По поводу кэша: что-то я не слышал про сторонние либы для кеширования кишков хибера. Да и странно это было бы. Хибер-то лучше знает что ему надо - это он рулит ентити-объектами.

Про вызов: нет, это ядро JSF само дёргает, для своих нужд.


Уточнить просто хочется: после добавления @Transactional виснуть перестало?

Да после добавления @Transactional виснуть перестало. И помойму я даже понял почему ... дело в том что висло при запросе select ... и видимо хибер делал не простой select а что то вроде select for update. И из за частого выполнения этого запроса ( из за JSF ) делался дед лок на базу и и за этого все висло.