I spent some time investigating the problem - results: - The problem is not related to thread locals. - The memory costs using layout tag with ~2MB sized pages is significant. Without layout tag the test (20 threads parallel same page) took around 35MB, with layout tag around 190MB - After this test has passed the memory usage did not drop below 100MB using stripes layout, without layout tag it did not drop under 10MB (after requesting gc multiple times) - The app crashed with heap space exceptions when running with 100MB max heap and stripes layout tag. It did not without stripes layout tag. It is important to state that the app crashed after 40 requests. So the memory got filled up with each request. - I ran a test using stripes layout tag with 2 threads running request after request for over 25 hours and the app is not leaking. The memory usage did not drop below 100MB (after requesting gc multiple times).
Conclusion There is no memory leak is stripes layout tag (currently ;-P ) There are still open questions: - Why is the memory not released by gc after a request is finished - Why is the memory not released by gc after a request is finished is increasing until reaching some magic random numbers around 100MB - Can this behavior be reproduced in other containers eg. Jetty? I think it is related to the tomcat buffer, the limit buffer = true setting and that stripes layout tag is somehow referencing/using this buffer. Many thanks to Ben, Richard On Wed, May 12, 2010 at 10:27 AM, M.C.S. <m...@syn-online.de> wrote: > Hi Ben, > > could you please check in the patch into the 1.5.x and, if needed, the > 1.4.x branches? Currently we are not using the version on trunk, but > also would like to benefit from the fix asap. > > Marcus > > > Am 11.05.2010 17:10, schrieb Ben Gunter: >> 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 > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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
