I am aware of the faults with the layout tags. You guys pretty well understand it, based on what you've written in this thread. Yes, when you use layout tags the whole contents of the page is cached and then written out at once. I wanted to fix it for 1.5.2 so that it would stream content to the client, but it turned out to be very complicated. I'm not even sure it is possible to fix it without changing how the tags work, which would break backwards compatibility.
As Richard pointed out, the appearance off a memory leak is probably due to tag pooling in the app server, coupled with the layout tags' caching of large pages. There was some discussion of that problem a while back, but I can't remember if it was on this mailing list or in JIRA or on IRC. -Ben On Sat, May 1, 2010 at 2:08 AM, Richard Hauswald < richard.hausw...@googlemail.com> wrote: > Nikolaos, > thanks for the pointer. I noticed the performance issues while > rendering a site wit about 2MB content. Also it doesn't explain the > leak, it explains the slow performance and memory hunger. Maybe it is > important to mention that I'm using nested layouts. IMHO: Since > stripes handles this situation by using variables they must end up in > giant strings causing memory and performance issues. > > I'll give the 1.5.3 try, didn't find the time to deploy it to our > company repository yet. > > > As far as Danil's comment on "... since restarting tomcat once in a while > > seemed to be rather sufficient solution ..." may be fine if you are > building > > personal apps or toying with a framework but isn't OK when it comes to > > serious production apps. > Agreed, also I might be that this is a state of the art workaround to > the memory leaks caused by using threadPools in combination with > threadLocals and the IMHO horrible default tomcat setup. > <OFFTOPIC> > After a bit of rtfm I found the following: > > "Use java system property at server runtime to disable tag pooling > org.apache.jasper.runtime.JspFactoryImpl.USE_POOL=false. and limit the > buffering with org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true. > Note that changing from the defaults may affect performance, but > depending on the application." > > This is only half of the truth as my profiler told me... In order to > completely disable the pool I had to add: > org.apache.jasper.runtime.JspFactoryImpl.POOL_SIZE=0. > I still do not understand why they are using thread locals. Pooling > will only work on a per thread level. Depending on the setup this > could mean that each of your 300 threads is holding a 40MB ThreadLocal > for the TagPool. ForEach tag does not clear its reference to the > collection. Tag pooling makes for each tag reside in thread local. If > the collection is a big list of entities with many references this is > more INSANE than just memory hungry. ThreadPooling mixes all the the > thread locals around the application. IMHO this could lead to > unintended data exposure. And why? Just to save 20 Object creations? > The only thing that kind of helps against the thread local fraction is > to set up the thread pool with a thread time out of 1ms - which > disables thread pooling(YEEHAA :-(). Without thread pooling > threadLocals won't hurt your memory. But that's only my thoughts. > </OFFTOPIC> > > On Sat, May 1, 2010 at 12:38 AM, Nikolaos Giannopoulos > <nikol...@brightminds.org> wrote: > > Richard, > > > > As 1.5.3 has only 2 fixes that appear unrelated to this issue... I take > it > > trying it won't make a difference? > > > > Also I came across this just today - albeit it was initially reported > > against 1.4.3 - but it is still OPEN: > > http://www.stripesframework.org/jira/browse/STS-391 > > > > As far as Danil's comment on "... since restarting tomcat once in a while > > seemed to be rather sufficient solution ..." may be fine if you are > building > > personal apps or toying with a framework but isn't OK when it comes to > > serious production apps. > > > > --Nikolaos > > > > > > > > > > Richard Hauswald wrote: > > > > Hi, > > I'm using > > apache-tomcat-6.0.26 and stripes 1.5.2 from repo1.maven.org. The > > memory keeps growing over the time, but not much. The leak is somehow > > referencing the jsp pool. That's why the size of the leak depends on > > the objects referenced by the jsp pool. In case of a nice forEach over > > a big business object collection... > > Thanks for your feedback, > > Richard > > > > On Thu, Apr 29, 2010 at 7:40 PM, Daniil Sosonkin <dan...@orbisfn.com> > wrote: > > > > > > I did notice potential memory leaks while using older version of Stripes. > Do > > note that I've never actually investigated since restarting tomcat once > in a > > while seemed to be rather sufficient solution, but the webapp started to > eat > > memory only after introduction of Stripes. But after most recent upgrade, > > the issue has went away. So I've never actually bothered to investigate. > > Could you tell which version of Tomcat + Stripes you were testing > against. > > And does the memory keep growing with time? I'm running many live sites > on > > Stripes now so very concerned with memory leaks, but haven't noticed any > in > > the past month or so. > > > > Daniil > > > > Richard Hauswald wrote: > > > > Hello List, > > while chasing jsp memory leaks I found that using the stripes layout > > tag has 3 negative effects: > > 1. this tag doubles the memory usage in compare to using @include > > 2. this tag is slow > > 3. this tag creates memory leaks. after 100 requests (maxThreads = 10 > > at the ajp processors ThreadPool) to the same jsp the leak consumes > > about 60MB (PS Old Gen) because of references to the jsp runtime > > context. I do have a heap dump available, please ask if you need it ~ > > 90MB > > > > Is anyone experiencing the same problems? Maybe this problem is a > > tomcat/apache jsp issue, so I'd be happy to hear about the tags > > behavior in other containers/app servers > > > > Best Regards, > > Richard > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Stripes-users mailing list > > Stripes-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/stripes-users > > > > > > > > > > > > > > -- > > Nikolaos Giannopoulos > > Director, BrightMinds Software Inc. > > e. nikol...@brightminds.org > > w. www.brightminds.org > > t. 1.613.822.1700 > > c. 1.613.797.0036 > > f. 1.613.822.1915 > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > 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
