Re: jetty out of memory reloading spring app
Dub, Your ClassCast exceptions indicate that you have a class that is loaded by your webapp's classloader (and therefore changes on each redeploy) but that is set statically on some classes that are in the system classpath (which doesn't change with each redeploy). I recently found a bug in the version of Jasper (Tomcat's JSP engine) that is also used by Jetty6. I've fixed it for Jetty and told the Tomcat team about it. This may apply to you if you are using JSPs and are using JDK1.5, so you may want to give a recent SNAPSHOT of the plugin a whirl. Instructions on that can be found from http://jetty.mortbay.org/jetty6/index.html cheers Jan gdub wrote: Stephen Duncan wrote: 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. That would explain it. I wonder why the difficulty with releasing unreferenced class loaders. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty out of memory reloading spring app
Stephen Duncan wrote: 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. That would explain it. I wonder why the difficulty with releasing unreferenced class loaders. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty out of memory reloading spring app
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]
Re: jetty out of memory reloading spring app
I wrote: > It does say that it's PermGen space > memory that's the problem. I'll look > at the article you mention tomorrow > and see if it helps. I increased the perm memory to 128Mb as a responder on the blog suggested. MAVEN_OPTS='-XX:MaxPermSize=128m' Now, I'm not getting the out-of-memory errors. One new weirdness is that now almost every time a class definition changes, the Jetty plug-in has to be restarted to avoid cast exceptions. I wonder if by setting MAVEN_OPTS (which wasn't set before) in the environment, some implicit setting was changed. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty out of memory reloading spring app
> 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 Thank you, Rolf- It does say that it's PermGen space memory that's the problem. I'll look at the article you mention tomorrow and see if it helps. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty out of memory reloading spring app
Thanks, Jan- > 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. I'll try that. > Are the spring jars explicitly on the plugin's > classpath or are they as dependencies of the > project? All dependencies are configured in Maven using the pom.xml dependencies section. I didn't even know the plug-in had its own classpath config options. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty out of memory reloading spring app
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] > >
Re: jetty out of memory reloading spring app
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]
Re: jetty out of memory reloading spring app
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]
jetty out of memory reloading spring app
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]
