I did a little poking around and found that sometime in 2008, LayoutComponentTag was changed such that it does not null its reference to its BodyContent. Apparently it had to do with a bug in Resin, but I suspect it might have led to a memory leak. The JSP spec is clear that setBodyContent is to be called after each call to doStartTag() that returns EVAL_BODY_BUFFERED so there's no reason to retain a reference to the BodyContent. I've reverted that change in the trunk. Can you check out and build the trunk and see if that helps the memory issues?
-Ben On Tue, May 11, 2010 at 9:11 AM, Richard Hauswald < richard.hausw...@googlemail.com> wrote: > Hey Ben, > I think there is leak even tag pooling is disabled. I am using the > current version of tomcat and disabled tag pooling. Did some other > modifications too so here is the sum: > CATALINA_OPTS='-Djava.awt.headless=true -Dserver.info=IIS -server > -Xmx100M -Xms80M -XX:MaxPermSize=60M -XX:PermSize=30M' > > #MemoryLeakPrecausions > CATALINA_OPTS="$CATALINA_OPTS > -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true > -Dorg.apache.jasper.runtime.JspFactoryImpl.USE_POOL=false > -Dorg.apache.jasper.runtime.JspFactoryImpl.POOL_SIZE=0" > > #GarbageCollectionTuning > CATALINA_OPTS="$CATALINA_OPTS -XX:+CMSClassUnloadingEnabled > -XX:-UseGCOverheadLimit" > > If I am not using stripes layout tag the app isn't leaking. If I am > using the layout tag the app starts leaking. That's why I suspect the > layout tag to be the guilty guy in this thriller :-) > > I still have the heap dump available but its around 80mb big... say a > word if you need it. Thats why I only send the report including the > results of shortest path to gc analysis: > One instance of "org.apache.jasper.servlet.JspServlet" loaded by > "org.apache.catalina.loader.StandardClassLoader @ 0x7f44d9b865c0" > occupies 76.998.232 (89,65%) bytes. The memory is accumulated in one > instance of > "org.apache.jsp.WEB_002dINF.jsp_002dlayouts.app.MainLayoutApp_jsp" > loaded by "JSPs of null".Keywords > org.apache.jsp.WEB_002dINF.jsp_002dlayouts.app.MainLayoutApp_jsp > JSPs of null > org.apache.catalina.loader.StandardClassLoader @ 0x7f44d9b865c0 > org.apache.jasper.servlet.JspServlet > > > Shortest Paths To the Accumulation Point > Class Name Shallow Heap Retained Heap > org.apache.jsp.WEB_002dINF.jsp_002dlayouts.app.MainLayoutApp_jsp @ > 0x7f44da16f020 80 76.961.568 > theServlet org.apache.jasper.servlet.JspServletWrapper @ > 0x7f44da16f0a0 120 76.963.208 > value java.util.concurrent.ConcurrentHashMap$HashEntry @ > 0x7f44da174660 48 76.963.256 > [0] java.util.concurrent.ConcurrentHashMap$HashEntry[1] @ > 0x7f44d9f83a40 32 76.963.288 > table java.util.concurrent.ConcurrentHashMap$Segment @ 0x7f44d9f839e0 > 48 76.963.384 > [4] java.util.concurrent.ConcurrentHashMap$Segment[16] @ > 0x7f44d9f833c8 152 76.983.992 > segments java.util.concurrent.ConcurrentHashMap @ 0x7f44d9f83380 72 > 76.984.088 > jsps org.apache.jasper.compiler.JspRuntimeContext @ 0x7f44d9f832d8 96 > 76.996.968 > rctxt org.apache.jasper.servlet.JspServlet @ 0x7f44d9f82d68 64 76.998.232 > resource org.apache.tomcat.util.modeler.BaseModelMBean @ > 0x7f44d9d3c978 64 1.088 > object com.sun.jmx.mbeanserver.NamedObject @ 0x7f44d9d3c958 32 32 > value java.util.HashMap$Entry @ 0x7f44d9d3c900 48 120 > [43] java.util.HashMap$Entry[128] @ 0x7f44d9d07340 1.048 8.288 > table java.util.HashMap @ 0x7f44d9bbc4f0 64 8.376 > value java.util.HashMap$Entry @ 0x7f44d9bbc4c0 48 8.504 > [4] java.util.HashMap$Entry[16] @ 0x7f44d9be1220 152 21.872 > table java.util.HashMap @ 0x7f44d9b99508 64 21.984 > domainTb com.sun.jmx.mbeanserver.Repository @ 0x7f44d9b994e0 40 22.024 > repository com.sun.jmx.interceptor.DefaultMBeanServerInterceptor @ > 0x7f44d9b99070 80 113.672 > mbsInterceptor com.sun.jmx.mbeanserver.JmxMBeanServer @ 0x7f44d9b86428 > 64 115.080 > platformMBeanServer class java.lang.management.ManagementFactory @ > 0x7f44d60ea788 System Class 88 584 > [0] java.lang.Object[10] @ 0x7f44d99b96e0 » 104 104 > mserver org.apache.catalina.core.StandardEngine @ 0x7f44d9bd8170 » 256 > 1.264 > Total: 3 entries > instance org.apache.catalina.core.StandardWrapper @ 0x7f44d9c27720 » 376 > 2.640 > Total: 2 entries > > Accumulated Objects > Class Name Shallow Heap Retained Heap Percentage > org.apache.jasper.servlet.JspServlet @ 0x7f44d9f82d68 64 76.998.232 89,65% > org.apache.jasper.compiler.JspRuntimeContext @ 0x7f44d9f832d8 96 > 76.996.968 89,65% > java.util.concurrent.ConcurrentHashMap @ 0x7f44d9f83380 72 76.984.088 > 89,63% > java.util.concurrent.ConcurrentHashMap$Segment[16] @ 0x7f44d9f833c8 > 152 76.983.992 89,63% > java.util.concurrent.ConcurrentHashMap$Segment @ 0x7f44d9f839e0 48 > 76.963.384 89,61% > java.util.concurrent.ConcurrentHashMap$HashEntry[1] @ 0x7f44d9f83a40 > 32 76.963.288 89,61% > java.util.concurrent.ConcurrentHashMap$HashEntry @ 0x7f44da174660 48 > 76.963.256 89,61% > org.apache.jasper.servlet.JspServletWrapper @ 0x7f44da16f0a0 120 > 76.963.208 89,61% > org.apache.jsp.WEB_002dINF.jsp_002dlayouts.app.MainLayoutApp_jsp @ > 0x7f44da16f020 80 76.961.568 89,61% > org.apache.jasper.runtime.TagHandlerPool @ 0x7f44da1706f8 48 13.367.392 > 15,56% > org.apache.jasper.runtime.TagHandlerPool @ 0x7f44da170768 48 8.929.176 > 10,40% > org.apache.jasper.runtime.PageContextImpl @ 0x7f44daf72eb8 128 8.928.208 > 10,39% > org.apache.jasper.runtime.PageContextImpl @ 0x7f44dcd48f00 128 8.928.208 > 10,39% > org.apache.jasper.runtime.PageContextImpl @ 0x7f44dde5fe70 128 8.928.208 > 10,39% > org.apache.jasper.runtime.PageContextImpl @ 0x7f44da6ecd50 128 5.585.872 > 6,50% > net.sourceforge.stripes.tag.layout.LayoutComponentTag @ 0x7f44dda1a5e0 > 72 4.456.280 5,19% > net.sourceforge.stripes.tag.layout.LayoutDefinitionTag @ > 0x7f44dde63f98 48 4.454.296 5,19% > net.sourceforge.stripes.tag.layout.LayoutDefinitionTag @ > 0x7f44da16f070 48 4.454.280 5,19% > net.sourceforge.stripes.tag.layout.LayoutDefinitionTag @ > 0x7f44da178460 48 4.454.280 5,19% > net.sourceforge.stripes.tag.layout.LayoutDefinitionTag @ > 0x7f44dc9063d0 48 4.454.280 5,19% > org.apache.jasper.runtime.JspWriterImpl @ 0x7f44deb232f8 80 16.488 0,02% > org.apache.jasper.runtime.BodyContentImpl @ 0x7f44deb281d8 80 1.128 0,00% > org.apache.jasper.runtime.BodyContentImpl @ 0x7f44deb28668 80 1.128 0,00% > org.apache.jasper.runtime.TagHandlerPool @ 0x7f44da1707d8 48 816 0,00% > org.apache.jasper.runtime.PageContextImpl @ 0x7f44deb23238 128 512 0,00% > org.apache.jasper.runtime.TagHandlerPool @ 0x7f44da170550 48 296 0,00% > java.lang.String @ 0x7f44d7f6f558 > /WEB-INF/jsp-layouts/pub/MainLayoutPub.jsp 40 144 0,00% > org.apache.jasper.runtime.TagHandlerPool @ 0x7f44da170688 48 112 0,00% > java.lang.String @ 0x7f44d7f6fe68 menuAbove 40 80 0,00% > Total: 20 entries 1.464 76.961.184 0,896 > > Accumulated Objects by Class > Label Number Of Objects Used Heap Size Retained Heap Size > org.apache.jasper.runtime.PageContextImpl 5 640 32.371.008 > org.apache.jasper.runtime.TagHandlerPool 5 240 22.297.792 > net.sourceforge.stripes.tag.layout.LayoutDefinitionTag 4 192 17.817.136 > net.sourceforge.stripes.tag.layout.LayoutComponentTag 1 72 4.456.280 > org.apache.jasper.runtime.JspWriterImpl 1 80 16.488 > org.apache.jasper.runtime.BodyContentImpl 2 160 2.256 > java.lang.String 7 280 488 > char[] 1 40 40 > java.lang.Class 2 0 0 > Total: 9 entries 28 1.704 76.961.488 > > > Table Of ContentsCreated by Eclipse Memory Analyzer > > I'll also send you a few screenshots directly(I'm not sure if everyone > on this list likes receiving png attachements from a mailing list) so > you can have a look at the formatted results. Thanks for your help, > Richard > > On Tue, May 11, 2010 at 2:39 PM, Ben Gunter <gunter...@gmail.com> wrote: > > As far as I know, this is not a leak, per se. It is caused by tag > pooling, > > which is the container *intentionally* holding stuff in memory so it can > be > > reused instead of creating new objects each time they're needed. > Containers > > can be configured to disable tag pooling if it causes a problem. > > I understand that people don't like the fact that layout tags buffer > > (sometimes large amounts of) data before finally sending it to the > client, > > but it is a known limitation at this point. If it causes a problem, then > I > > advise you not to use the layout tags in that case. > > If anybody can prove to me that Stripes itself is actually leaking memory > > then I'll take a look at fixing that. > > One day I will again look into making the layout tags stream data to the > > client, but I doubt it can be done without breaking some quirky aspect of > > the tags that somebody might actually be using. I wouldn't hold my breath > > waiting on a solution if I were you. It will likely have to wait until > 1.6. > > -Ben > > > > On Tue, May 11, 2010 at 3:59 AM, Richard Hauswald > > <richard.hausw...@googlemail.com> wrote: > >> > >> Hello @all, > >> IMHO using stripes layout is a good thing - well if the tag will be > >> fixed to stream and the memory leak is removed :-) I don't think jsp > >> tag files should be used for as website templates / layout solution. > >> But they should be used for building components like buttons or modal > >> dialog screens even including java script calls. So stripes layout for > >> the main big layout (even nested) but jsp tag files for simple > >> components. Complex components should be built using custom jsp tags. > >> I totally agree with Karen - we should respect the mvc pattern. Using > >> stripes and jsp this is just too easy :-) > >> > >> > In all this though is Stripes using ThreadLocal somewhere? If so, is > it > >> > not using the "remove" method on ThreadLocal to cleanup the data? If > it is > >> > using ThreadLocal but > not using "remove" then this is a SERIOUS bug > >> > IMHO... > >> I'm not sure which mad and ugly reference the leak produces. Tried > >> fixing it for 10 minutes only, setting the members of the jsp tag file > >> null - without success. The inheritance hierarchy makes it complicated > >> to detect all references in a short time. I do agree that at least > >> this leak should be fixed. > >> @Ben > >> Are going to find some time to hunt this leak? > >> > >> Regards, > >> Richard > >> > >> > >> > >> On Thu, May 6, 2010 at 3:15 PM, KR <k-no-s...@a4consulting.nl> wrote: > >> > Nikolaos, > >> > > >> > If you are using JSP as a view technology in an MVC pattern, then IMO > >> > you > >> > should not want to use scriptlets in you're JSP. Because what ever you > >> > want > >> > to do in a scriptlet is the responsibility of the controller a.k.a. > >> > Action > >> > Bean. Seen this way, it's actually a good thing that JSP tag files > >> > enforce > >> > the MVC pattern boundaries. > >> > > >> > The major benefit of JSP tag files is that they stream their output as > >> > it > >> > comes available. The Stripes layout tags, does not seem to do this (I > >> > think > >> > it starts streaming after the whole layout is out evaluated). This > will > >> > slow > >> > down perceived performance of you're website, especially on complex or > >> > big > >> > pages. > >> > > >> > The drawback of JSP tag files is that they only have one body. But a > >> > Stripes > >> > layout tag can have multiple body parts (named layout components). > This > >> > is a > >> > more flexible way of declaring templates and I did not yet find a good > >> > replacement for doing this just as good with JSP tag files. The JSP > tag > >> > files thus result in a less flexible template structure. > >> > > >> > > >> > > >> > Karen > >> > > >> > > >> > > >> > "Nikolaos Giannopoulos" <nikol...@brightminds.org> > >> > wrote in message news:4be24d0f.5050...@brightminds.org... > >> >> Will, > >> >> > >> >> Thanks for the input. This caught my attention about at least one > >> >> particular benefit of Stripes Layout over Tag Files: > >> >> > >> >> http://www.stripesframework.org/display/stripes/Layout+Reuse > >> >> > >> >> *Page fragment layouts > >> >> * > >> >> This might be obvious, but you can also use a layout to control how a > >> >> small piece of a page renders. Using the layout tags in this way is > >> >> very > >> >> similar to using the new JSP tag files which allow you to write > custom > >> >> tags using JSP fragments. /_With on important difference. While you > can > >> >> pass the result of JSP fragments to a tag file, those fragments > cannot > >> >> contain any scriptlets._/ Often this isn't a problem, but sometimes > it > >> >> can get in the way. > >> >> > >> >> It remains to be seen (yet) if this benefit will matter much in our > >> >> case > >> >> though I am curious if anyone end up using Stripes Layout over JSP > tag > >> >> files b/c of this??? And why? An example is cited at the URL above > >> >> but > >> >> I doubt I would ever want to do anything like that. > >> >> > >> >> --Nikolaos > >> >> > >> >> > >> >> > >> >> Will Hartung wrote: > >> >>> Nikolaos, > >> >>> > >> >>> I can't comment on Stripes Layout memory consumption, nor the use of > >> >>> Tiles. > >> >>> > >> >>> I can only follow up with what Richard said about JSP 2.0 Tag Files. > >> >>> > >> >>> I've not used Tiles or Stripes Layout simply because Tag Files > exist, > >> >>> and > >> >>> I use those instead. > >> >>> > >> >>> JSP Tag Files effectively are as memory efficient (or inefficient) > as > >> >>> JSP > >> >>> pages are themselves, since that's effectively all they are -- JSP > >> >>> files > >> >>> converted to code and dynamically run at page render time. > >> >>> > >> >>> Tag Files allow for ready refactoring and adding the right amount of > >> >>> abstractions to your JSPs. > >> >>> > >> >>> Regards, > >> >>> > >> >>> Will Hartung > >> >>> > >> >>> > >> >> > >> > > >> > > >> > > >> > > -------------------------------------------------------------------------------- > >> > > >> > > >> >> > >> >> > ------------------------------------------------------------------------------ > >> >> > >> > > >> > > >> > > >> > > -------------------------------------------------------------------------------- > >> > > >> > > >> >> _______________________________________________ > >> >> Stripes-users mailing list > >> >> Stripes-users@lists.sourceforge.net > >> >> https://lists.sourceforge.net/lists/listinfo/stripes-users > >> >> > >> > > >> > > >> > > >> > > >> > > >> > > ------------------------------------------------------------------------------ > >> > _______________________________________________ > >> > Stripes-users mailing list > >> > Stripes-users@lists.sourceforge.net > >> > https://lists.sourceforge.net/lists/listinfo/stripes-users > >> > > >> > >> > >> > >> -- > >> Richard Hauswald > >> Blog: http://tnfstacc.blogspot.com/ > >> LinkedIn: http://www.linkedin.com/in/richardhauswald > >> Xing: http://www.xing.com/profile/Richard_Hauswald > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Stripes-users mailing list > >> Stripes-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/stripes-users > > > > > > > ------------------------------------------------------------------------------ > > > > > > _______________________________________________ > > Stripes-users mailing list > > Stripes-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/stripes-users > > > > > > > > -- > Richard Hauswald > Blog: http://tnfstacc.blogspot.com/ > LinkedIn: http://www.linkedin.com/in/richardhauswald > Xing: http://www.xing.com/profile/Richard_Hauswald > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Stripes-users mailing list > Stripes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/stripes-users >
------------------------------------------------------------------------------
_______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
