Bugs item #435958, was opened at 2001-06-24 21:53 Message generated for change (Comment added) made by hal200 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=435958&group_id=22866
Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Schaefer (schaefera) Summary: Out of Memory eception after many redepl Initial Comment: This behavior has been observed on Windows 2000 SP2, running Sun JDK 1.3.1 and jBoss2.2.2 both Tomcat and Jetty bundles. After many EAR hot redeployments in a short period of time, (prehaps one every 5 to 20 minutes over a period of 6 hours) a redeployment will result in "Out of Memory" exceptions being thrown. This happens with both the Tomcat and Jetty bundles, but the error is much more clear with Jetty. In the case of Tomcat, it appears to redeploy correctly but creates a variety of errors when the app is run. ---------------------------------------------------------------------- Comment By: Jonathan Kovacs (hal200) Date: 2003-11-12 17:39 Message: Logged In: YES user_id=907916 I'm getting the same problem with JBoss 3.2.1_Tomcat-4.1.24. In my case, it seems to be triggered by a strange interaction with the Struts libraries. I threw together a quick script which continuously re-deploys the struts-example.war file over and over again (with a 15 second pause between deploy/undeployments) by popping the file in and out of the deploy directory (instead of using the deployer.jar tool...not sure at this point if that would make a difference) Sure enough, when watching the GC output, the memory use keeps increasing. If I stop the script, the memory doesn't seem to ever get reclaimed. If I leave it running, eventually the server blows it's heap and I start getting OutOfMemory errors at random intervals. ------------------------------------------------------------------------------- 17:05:45,223 ERROR [URLDeploymentScanner] Failed to deploy: [EMAIL PROTECTED] url=file:/home/jon/cvs-test/canarie/lib/jboss-3.2.1_tomcat-4.1.24/server/canarie/deploy/IQXWeb.war, deployedLastModified=0 } org.jboss.deployment.DeploymentException: Could not create deployment: file:/home/jon/cvs-test/canarie/lib/jboss-3.2.1_tomcat-4.1.24/server/canarie/deploy/IQXWeb.war; - nested throwable: (java.lang.OutOfMemoryError) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:853) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613) at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy7.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:476) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:200) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:211) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:190) Caused by: java.lang.OutOfMemoryError ------------------------------------------------------------------------------- After leaving it for about an hour in this state, with GC details turned on, we can see that sure enough, the memory is not being reclaimed, despite the JVM's best efforts... Full GC [Tenured: 58303K->58303K(58304K), 0.3335490 secs] 64404K->64354K(64832K), 0.3336620 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3131040 secs] 64407K->64354K(64832K), 0.3131720 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3122840 secs] 64397K->64354K(64832K), 0.3123480 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3455040 secs] 64397K->64354K(64832K), 0.3455610 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3205630 secs] 64397K->64354K(64832K), 0.3206770 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3148190 secs] 64398K->64354K(64832K), 0.3148690 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3124290 secs] 64397K->64354K(64832K), 0.3125430 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3098440 secs] 64397K->64354K(64832K), 0.3099050 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3316150 secs] 64397K->64354K(64832K), 0.3317300 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3237010 secs] 64397K->64354K(64832K), 0.3238340 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3266160 secs] 64397K->64354K(64832K), 0.3266670 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.4335870 secs] 64397K->64354K(64832K), 0.4336530 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3097620 secs] 64397K->64354K(64832K), 0.3098310 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3138060 secs] 64398K->64354K(64832K), 0.3139190 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3125410 secs] 64397K->64354K(64832K), 0.3125970 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3188110 secs] 64397K->64354K(64832K), 0.3189260 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3175270 secs] 64397K->64354K(64832K), 0.3175970 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3120930 secs] 64397K->64354K(64832K), 0.3121500 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3116510 secs] 64397K->64354K(64832K), 0.3117170 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3098090 secs] 64397K->64354K(64832K), 0.3098610 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3256830 secs] 64398K->64354K(64832K), 0.3257470 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3076290 secs] 64397K->64354K(64832K), 0.3076920 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3166820 secs] 64397K->64354K(64832K), 0.3167470 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.5335920 secs] 64397K->64354K(64832K), 0.5336590 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3426230 secs] 64397K->64354K(64832K), 0.3427690 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.4453350 secs] 64397K->64354K(64832K), 0.4453950 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3081930 secs] 64397K->64354K(64832K), 0.3082590 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3183000 secs] 64398K->64354K(64832K), 0.3183600 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3121360 secs] 64397K->64354K(64832K), 0.3121970 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3134370 secs] 64397K->64354K(64832K), 0.3134990 secs] [Full GC [Tenured: 58303K->58303K(58304K), 0.3156870 secs] 64397K->64354K(64832K), 0.3157560 secs] ---------------------------------------------------------------------- Comment By: Heiko W.Rupp (pilhuhn) Date: 2003-09-29 05:17 Message: Logged In: YES user_id=217112 I also see the growth on 3.2.2rc5 as of this morning. With a 4MB ear I get the follwing memory consumption on Win2k with jdk 1.4.2_b28: -Xmx256m -XX:MaxPermSize=128m mem virt mem (xxx.000 MB as size unit) 92 116 105 127 118 144 130 152 142 167 150 174 then I stopped. No out of memory exception so far. -Xmx256m -XX:MaxPermSize=128m mem virt mem (xxx.000 MB as size unit) 89 94 100 112 114 130 123 143 131 152 139 160 then I stopped. Also no oom exception. ---------------------------------------------------------------------- Comment By: Juha Lindfors (juhalindfors) Date: 2003-09-26 13:35 Message: Logged In: YES user_id=175239 Does changing the GC permanent collection size have an effect on how quickly you get OutofMemoryException? JDK 1.4.2, -XX:MaxPermSize=<nn>m ---------------------------------------------------------------------- Comment By: Tim McCune (javajedi) Date: 2003-09-25 18:22 Message: Logged In: YES user_id=62441 This still happens as of version 3.2. ---------------------------------------------------------------------- Comment By: Juha Lindfors (juhalindfors) Date: 2003-09-25 17:51 Message: Logged In: YES user_id=175239 Resubmit with a more recent JBoss version if you believe this is still a problem. ---------------------------------------------------------------------- Comment By: Tim McCune (javajedi) Date: 2003-03-17 17:07 Message: Logged In: YES user_id=62441 This is still happening. See http://jboss.org/forums/thread.jsp?forum=121&thread=27888 Can you please reopen this bug? ---------------------------------------------------------------------- Comment By: Andreas Schaefer (schaefera) Date: 2001-10-29 21:07 Message: Logged In: YES user_id=70434 Need more information about what is deployed. Unfortunately memory is always limited and therefore hot deployment will one time reach a limit because all the loaded classes are not removed from the classloaders. But to see where a problem is I have to know what is deployed and maybe a error stack trace. ---------------------------------------------------------------------- Comment By: Andreas Schaefer (schaefera) Date: 2001-10-29 21:03 Message: Logged In: YES user_id=70434 Need more information about what is deployed. Unfortunately memory is always limited and therefore hot deployment will one time reach a limit because all the loaded classes are not removed from the classloaders. But to see where a problem is I have to know what is deployed and maybe a error stack trace. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=435958&group_id=22866 ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development