Dobry den,
mame stejny problem a po desitkach hodin jeho reseni se nezda byt v
nasich silach jej vyresit. JSTL jsme v nasem pripade z okruhu
podezrelych vyloucili. Kvalitni vstupni branou ke studiu tohoto problemu
je
http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
.
S pozdravem
Petr
--
Bc. Petr Matulík
MoroSystems
+420 605 409 300
[EMAIL PROTECTED]
http://morosystems.cz
ales napsal(a):
Dobry den,
na zaklade osobnej skusenosti by som Vam odporucil:
- preverit konfiguraciu Tomcat
(http://tomcat.apache.org/tomcat-5.0-doc/jasper-howto.html,
http://jakarta.apache.org/tomcat/faq/memory.html)
- preverit JDBC ovladac ci neobsahuje memory leak (vid Bugzilla
prislusneho projektu, pripadne nieco obdobne)
- zmenit implicitne hodnoty JVM
(http://blogs.sun.com/roller/resources/watt/jvm-options-list.html)
- preverit aplikaciu pomocou profilera ci neobsahuje memory leak (nie
je to sice profiler, ale dobru skusenost mam aj s GCViewer -
http://www.tagtraum.com/gcviewer.html)
Ales
Benda Lukas wrote:
Zacal jsem pouzivat tomcar, spring (jstl) a hibernate, misto
jednoduchych JSP a servletu na strankach. Problem je ale s obsazenim
pameti. Pri lazeni musim aplikaci nekolikrat spoustet a reloadovat,
bezne se jiz po druhem reloadu (od restartu Tomcatu), zacne vsechno
zpomalovat a pritom pamet obsazena Tomcatem narusta. Po sestem az
sedmem reloadu dojde k "heapu" a musim restartovat Tomcat.
Podle prispevku "Memoryleak v jstl?" to vypada ze za problemu muze
jstl. Da se s tim neco delat? Preci kdyby to delalo i v ostrem
provozu tak aplikaci neni mozno vubec nasazovat, ne?
Vyresi problem prechod napr. na Jetty?
