Also look at the second question in this FAQ: http://tomcat.apache.org/faq/deployment.html
It explains why reloading an app causes this problem to show up more quickly. The description sounds like it would apply to any container that uses multiple classloaders, not just Tomcat, so it's likely true for Jetty as well. -Stephen On 4/20/06, Rolf Strijdhorst <[EMAIL PROTECTED]> wrote: > Hi is this a problem with perm memory? if so I think it is the same problem > Matt Railble describes on his blog: > http://raibledesigns.com/page/rd/20060419 > > the fix is to collect the memory consumtion data and express a solution on > that problem by setting the perm mem size accordingly -XX:MaxPermSize=256m > to MAVEN_OPTS. > Matt says it to add to JAVA_OPTS but that doesn't really work for maven. > > On 4/20/06, Burkhard Graves <[EMAIL PROTECTED]> wrote: > > > > Hi, just a small remark: > > > > I experienced similar out-of-memory problems with my > > spring/hibernate-app after around 10 or 12 reloads - but under tomcat > > 5.5.12! I'm switching to jetty right now - as soon as everything is > > running (actually some other problems hinder me ;-) I'll tell you if I > > still have out-of-memory problems... > > > > Regards > > Burkhard > > > > Jan Bartel schrieb: > > > Hi dub, > > > > > > The jetty maven plugin is up to release beta14 > > > so I would give that a go and see if it helps > > > with your memory issue. > > > We don't currently have any reported issues with out-of-memory problems > > > for the plugin. The webapp > > > classloader is ditched and then re-created on > > > each restart so stuff loaded from the webapp's > > > dependencies and classes should not be leaking. > > > > > > Are the spring jars explicitly on the plugin's classpath or are they as > > > dependencies of the > > > project? > > > > > > regards > > > Jan > > > > > > > > > gdub wrote: > > >> I use the jetty6:run (6.0 beta 9) target > > >> to launch Jetty with my web app under > > >> integration. > > >> > > >> It has a not-too-extensive Spring/Hibernate > > >> configuration. Jetty detects code changes > > >> just fine but after maybe 10 reloads, it > > >> starts reporting out-of-memory problems > > >> and refuses to reload. The machine isn't > > >> out of memory so it's the JVM itself that > > >> hits a wall. > > >> > > >> Is this a known Jetty plug-in problem? Or > > >> should I be looking for memory leaks in > > >> Spring and Hibernate (or, e gads, my own > > >> code). Is there something I need to > > >> configure to make sure that Jetty releases > > >> all app objects before reloading? > > >> > > >> BTW, I also ran into out of memory > > >> problems under surefire when running > > >> integration tests but was able to solve > > >> it by using a singleton Spring application > > >> context as a class member. But it leads > > >> me to think that my Spring context isn't > > >> releasing everything when it stops being > > >> referenced (closing the context and > > >> explicitly setting all references to it > > >> null helped me get about 10 more tests > > >> in a run). > > >> > > >> This is really only an issue during this > > >> final integration phase so it's not too > > >> big a deal but it does stop the thought > > >> flow when it happens. It's also an appli- > > >> cation confidence issue but I will do > > >> some memory profiling later. > > >> > > >> > > >> TIA, > > >> > > >> -dub > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- Stephen Duncan Jr www.stephenduncanjr.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
