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
