Re: OutOfMemoryException while redeploying WAR
Hello, thanks for the answers (a lot of :) ). Yes it is en PermSpace Error and if it is a problem with the JavaVM... I have to life with that. It is only for developing an application. In production mode, there is no need for a redeploy. Thanks for your help -Ursprüngliche Nachricht- Von: user@geronimo.apache.org Gesendet: 25.04.07 17:44:44 An: user@geronimo.apache.org Betreff: Re: OutOfMemoryException while redeploying WAR On Apr 25, 2007, at 10:37 AM, [EMAIL PROTECTED] wrote: It's related to the way Sun's JVM handles class data and internalized string. They make the assumption that you'd never want that information flushed from the VM, so they put that chunk of memory out of the reach of the garbage collector (i.e. permanent generation). Unfortunately, when you redeploy an application, you're really attempting to remove a bunch of classes and replace them with new ones. That simply doesn't work with Sun's VM; you only end up with both the old and the new classes in PermGen, even if the old class data is no longer useful or even accessible. There's no way around this one if you're using Sun's VM. Raising the amount of memory available for the permanent generation is really only a stop gap measure. If you feel you're going to redeploy your app very often, you should look into using another VM. I personally use JRockit for development (which is when I do most of my redeployment), even if I only run Sun's VM for staging and production servers (in order to take advantage of the deeper testing done on that VM). That's not accurate. PermGen memory *is* GC'ed. However, a Class can only be GC'ed when its ClassLoader has been GC'ed. In Geronimo, when you deploy an application, one (or more) ClassLoaders are created to load your application classes. When you undeploy your application, we free up references to that ClassLoader. Once the ClassLoader has been GC'ed, the application classes will be GC'ed from the PermGen space. Denis describes the behavior of classes loaded by the System ClassLoader. Since the system ClassLoader will never be GC'ed, classes loaded by the System ClassLoader will never be GC'ed. That is not a problem for Geronimo, since application classes will never be loaded using the system ClassLoader... --kevan ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
Re: OutOfMemoryException while redeploying WAR
On Apr 26, 2007, at 5:43 AM, Jochen Zink wrote: Hello, thanks for the answers (a lot of :) ). Yes it is en PermSpace Error and if it is a problem with the JavaVM... I have to life with that. It is only for developing an application. In production mode, there is no need for a redeploy. There is/was a bug in the Sun 1.5 JRE which could account for your problem (forgot to mention). The bug has been fixed in later releases. I don't know precisely which version fixed the problem. I do know: the problem is fixed in 1.5.0_10-b03 the problem is not fixed in 1.5.0_07-87 (which means Mac OS X users are out-of-luck...) --kevan
OutOfMemoryException while redeploying WAR
Hello, I'm using Geronimo 1.1.1 and have a problem. I'm developing a little JSF-Webapplication. First, I deploy the WAR to geronimo and after modifiying the sources I redploy the application WAR. That works fine. But after a while, I get OutOfMemory Exceptions while redeploying. After restarting Geronimo, everythink is fine. Is this a bug, or a kind of wrong use of redeploy? Thanks regards Jochen Zink _ Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179
Re: OutOfMemoryException while redeploying WAR
That has to do with the PermSize. It is the classloader's memory. Set -XX:MaxPermSize=256M at startup. -- Dario Jochen Zink escreveu: Hello, I'm using Geronimo 1.1.1 and have a problem. I'm developing a little JSF-Webapplication. First, I deploy the WAR to geronimo and after modifiying the sources I redploy the application WAR. That works fine. But after a while, I get OutOfMemory Exceptions while redeploying. After restarting Geronimo, everythink is fine. Is this a bug, or a kind of wrong use of redeploy? Thanks regards Jochen Zink _ Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179
Re: OutOfMemoryException while redeploying WAR
It's related to the way Sun's JVM handles class data and internalized string. They make the assumption that you'd never want that information flushed from the VM, so they put that chunk of memory out of the reach of the garbage collector (i.e. permanent generation). Unfortunately, when you redeploy an application, you're really attempting to remove a bunch of classes and replace them with new ones. That simply doesn't work with Sun's VM; you only end up with both the old and the new classes in PermGen, even if the old class data is no longer useful or even accessible. There's no way around this one if you're using Sun's VM. Raising the amount of memory available for the permanent generation is really only a stop gap measure. If you feel you're going to redeploy your app very often, you should look into using another VM. I personally use JRockit for development (which is when I do most of my redeployment), even if I only run Sun's VM for staging and production servers (in order to take advantage of the deeper testing done on that VM). Hope it helps. * Denis Robert Senior Technical Architect BFM Insurance Group Phone: (441) 298-0344 Email: [EMAIL PROTECTED] * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. * Dario Andrade [EMAIL PROTECTED] 04/25/2007 11:31 AM Please respond to user@geronimo.apache.org To user@geronimo.apache.org cc Subject Re: OutOfMemoryException while redeploying WAR That has to do with the PermSize. It is the classloader's memory. Set -XX:MaxPermSize=256M at startup. -- Dario Jochen Zink escreveu: Hello, I'm using Geronimo 1.1.1 and have a problem. I'm developing a little JSF-Webapplication. First, I deploy the WAR to geronimo and after modifiying the sources I redploy the application WAR. That works fine. But after a while, I get OutOfMemory Exceptions while redeploying. After restarting Geronimo, everythink is fine. Is this a bug, or a kind of wrong use of redeploy? Thanks regards Jochen Zink _ Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179
Re: OutOfMemoryException while redeploying WAR
On Apr 25, 2007, at 10:31 AM, Dario Andrade wrote: That has to do with the PermSize. It is the classloader's memory. Set -XX:MaxPermSize=256M at startup. -- Dario Jochen Zink escreveu: Hello, I'm using Geronimo 1.1.1 and have a problem. I'm developing a little JSF-Webapplication. First, I deploy the WAR to geronimo and after modifiying the sources I redploy the application WAR. That works fine. But after a while, I get OutOfMemory Exceptions while redeploying. After restarting Geronimo, everythink is fine. Is this a bug, or a kind of wrong use of redeploy? Hi Jochen, You are using redeploy properly. There are different types of OutOfMemoryErrors. Your scenario suggests that you are running out of PermGen space (e.g. OutOfMemoryError: PermGen space). PermGen space is used by the Sun JRE to store loaded Classes. As Dario suggests, configuring the MaxPermSize to a larger value (default is 64M), may avoid the problem. However, if there is a ClassLoader memory leak, with each undeploy/deploy (e.g. redeploy), the amount of PermGen space being used will continue to grow. Increasing the PermGen size may only be postponing the inevitable OOME... ClassLoader memory leaks may be caused by application code or a Geronimo bug. We did test for Classloader memory leaks in 1.1.1 and I'm not aware of any bugs. I suggest you increase your MaxPermSize to 128M. If you continue to see a problem, then you'll need to dig a bit more. A good Java profiler is pretty useful in tracking down these problems. If you can make a testcase available, then probably someone in the community can take a look... (if you can recreate the problem on one of our 2.0 milestone drivers, then we'd definitely take a look... :) --kevan
Re: OutOfMemoryException while redeploying WAR
On Apr 25, 2007, at 10:37 AM, [EMAIL PROTECTED] wrote: It's related to the way Sun's JVM handles class data and internalized string. They make the assumption that you'd never want that information flushed from the VM, so they put that chunk of memory out of the reach of the garbage collector (i.e. permanent generation). Unfortunately, when you redeploy an application, you're really attempting to remove a bunch of classes and replace them with new ones. That simply doesn't work with Sun's VM; you only end up with both the old and the new classes in PermGen, even if the old class data is no longer useful or even accessible. There's no way around this one if you're using Sun's VM. Raising the amount of memory available for the permanent generation is really only a stop gap measure. If you feel you're going to redeploy your app very often, you should look into using another VM. I personally use JRockit for development (which is when I do most of my redeployment), even if I only run Sun's VM for staging and production servers (in order to take advantage of the deeper testing done on that VM). That's not accurate. PermGen memory *is* GC'ed. However, a Class can only be GC'ed when its ClassLoader has been GC'ed. In Geronimo, when you deploy an application, one (or more) ClassLoaders are created to load your application classes. When you undeploy your application, we free up references to that ClassLoader. Once the ClassLoader has been GC'ed, the application classes will be GC'ed from the PermGen space. Denis describes the behavior of classes loaded by the System ClassLoader. Since the system ClassLoader will never be GC'ed, classes loaded by the System ClassLoader will never be GC'ed. That is not a problem for Geronimo, since application classes will never be loaded using the system ClassLoader... --kevan
Re: OutOfMemoryException while redeploying WAR
You're correct. But there's been a lot of discussion surrounding this issue in the Tomcat forums. Maybe it's because the ClassLoaders don't get GC'ed correctly, but when Tomcat reloads an app, the class data seems to never get GC'ed. The same issue was found with Jetty, so it seems to be a VM issue. * Denis Robert Senior Technical Architect BFM Insurance Group Phone: (441) 298-0344 Email: [EMAIL PROTECTED] * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. * Kevan Miller [EMAIL PROTECTED] 04/25/2007 12:11 PM Please respond to user@geronimo.apache.org To user@geronimo.apache.org cc Subject Re: OutOfMemoryException while redeploying WAR On Apr 25, 2007, at 10:37 AM, [EMAIL PROTECTED] wrote: It's related to the way Sun's JVM handles class data and internalized string. They make the assumption that you'd never want that information flushed from the VM, so they put that chunk of memory out of the reach of the garbage collector (i.e. permanent generation). Unfortunately, when you redeploy an application, you're really attempting to remove a bunch of classes and replace them with new ones. That simply doesn't work with Sun's VM; you only end up with both the old and the new classes in PermGen, even if the old class data is no longer useful or even accessible. There's no way around this one if you're using Sun's VM. Raising the amount of memory available for the permanent generation is really only a stop gap measure. If you feel you're going to redeploy your app very often, you should look into using another VM. I personally use JRockit for development (which is when I do most of my redeployment), even if I only run Sun's VM for staging and production servers (in order to take advantage of the deeper testing done on that VM). That's not accurate. PermGen memory *is* GC'ed. However, a Class can only be GC'ed when its ClassLoader has been GC'ed. In Geronimo, when you deploy an application, one (or more) ClassLoaders are created to load your application classes. When you undeploy your application, we free up references to that ClassLoader. Once the ClassLoader has been GC'ed, the application classes will be GC'ed from the PermGen space. Denis describes the behavior of classes loaded by the System ClassLoader. Since the system ClassLoader will never be GC'ed, classes loaded by the System ClassLoader will never be GC'ed. That is not a problem for Geronimo, since application classes will never be loaded using the system ClassLoader... --kevan
Re: OutOfMemoryException while redeploying WAR
Maybe you are referring to this issue in tomcat: http://issues.apache.org/bugzilla/show_bug.cgi?id=42172 If so then that classloader leak was attributed to how log4j was used by the application. Best wishes, Paul On Apr 25, 2007, at 11:19 AM, [EMAIL PROTECTED] wrote: You're correct. But there's been a lot of discussion surrounding this issue in the Tomcat forums. Maybe it's because the ClassLoaders don't get GC'ed correctly, but when Tomcat reloads an app, the class data seems to never get GC'ed. The same issue was found with Jetty, so it seems to be a VM issue.
