Hi, have you tried to increase the JVM's permanent memory size? You obviously tried -Xmx to increase the heap to 3GB, but maybe try: -XX:PermSize=???m -XX:MaxPermSize=???m
setting this will cause the permanent memory to take a bigger part of the heap as set by -Xmx. Of course, this will not stop memory leakage, but depending on how often you reset, you might be able to shift e.g. container restarts into night time maintainance slots or something like that and get away with it. Also make sure that you didn't disable class garbage collection. Maybe it helps to monitor the GC activities by logging things with -Xloggc:<file> etc. E.g. if it's really a problem about "classes" gc, the runtime's freeMemory method won't tell you anything, if you're low on permanent memory and simply throws out of memory errors. Cheers Michael P.S. Might be useful for tuning and logging: http://java.sun.com/docs/hotspot/gc1.4.2/ http://java.sun.com/docs/hotspot/VMOptions.html Tomas Jucius wrote: > If I clean all ognl properties... The applicaiontion can't load, > because all beans ant other stuff disappears.. > > How easy I could get the state of OGNL properties like in just > initialized application? > > On 6/21/05, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > >>My theory is that the code related to Introspector and OGNL is holding >>onto references to outdated classes. >> >>On 6/21/05, Michael Musson <[EMAIL PROTECTED]> wrote: >> >>>On 6/17/05, Tomas Jucius <[EMAIL PROTECTED]> wrote: >>> >>>>But after a lot of resets jvm memory becomes full, and I get >>>>"java.lang.OutOfMemoryError" >>> >>>This issue has been raised in a previous thread. It was found that >>>setting the property disable-caching to true would eventually lead to >>>an out of memory exception and that setting the property to false >>>would prevent the exception from occurring. However since you are >>>calling the reset service you are creating the same situation through >>>different means. >>> >>>Here is Johan's original message below summarizing what he found: >>> >>>When I looked at this in Jan 31 (see archives) the error I ran into >>>was an OOME. When I looked at the actual stack-trace I could see that >>>it was the permanent heap that was out of memory. This is significant >>>since the permanent heap is used for storing classes and types. I have >>>never seen a profiler that analyses the permanent heap in detail - it >>>would be interesting to know if someone knows if such a tool exists. >>>The permanent heap is most probably never garbage collected, this >>>would amount to throwing away class definitions. This is usually not a >>>problem since an ordinary application has a finite number of classes >>>defined and when they are loaded that is it. >>>Now, when in development mode I assume, and this is just a guess, that >>>Tapestry is enhancing and creating _new_ classes every time a page is >>>loaded. This will fill the permanent heap after a while and when that >>>is full you'll get OOME. >>>When Tapestry can cache the classes it creates the permanent heap will >>>not fill up with new classes and everything should work as expected. >>>So this will only be a problem when in development mode, I wouldn't >>>even consider it a bug in Tapestry (this can happen with JSP compilers >>>also), merely a fact of life as a developer :-) >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >>-- >>Howard M. Lewis Ship >>Independent J2EE / Open-Source Java Consultant >>Creator, Jakarta Tapestry >>Creator, Jakarta HiveMind >> >>Professional Tapestry training, mentoring, support >>and project work. http://howardlewisship.com >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
