Just ran a very simple test using the changes from revision 642694 and had unusual results.
Byte arrays, and consequently the BufferedOutputStream still took up large amounts of retained space in the total memory usage. So, this didn't change. However, the memory did not clean up neatly like it did before...after about 10 minutes. Before, I would do, say 1000 samples, and total Tomcat memory would balloon to a point. Then I'd wait 10 minutes and would observe the byte array data cleaning up in the profiler with total Tomcat memory staying the same. After that, I'd run another 1000 samples and the total Tomcat memory would not increase again until hitting around the 1000th sample and the cycle would repeat. With these new changes, the memory cleaned up a little bit, but not nearly as much as before. And the total memory would start increasing before I hit the control sample size. The BufferedOutputStream path appears to be the same as well - flowing up to ContinuationsManagerImpl. Perhaps I'm doing something wrong? I did make this changes to version 2.1.10 NOT 2.1.11 since I haven't upgraded my site to the new version yet. --- footh <[EMAIL PROTECTED]> wrote: > Thanks Joerg...I was actually lurking this thread on the dev list to check on > the progress. > > I'll check out the new code and report back here with the results. > > > --- Joerg Heinicke <[EMAIL PROTECTED]> wrote: > > > On 27.03.2008 00:31, Joerg Heinicke wrote: > > > > >> Sure, here is the hierarchy from bottom to top. At this point, I ran > > >> the test for about five > > >> minutes (running longer would increase the percentage) and the > > >> retained size of the one > > >> ContinuationsManagerImpl object is 58% of the total. The > > >> BufferedOutputStream is 50% of the > > >> total, so the other 8% is consumed by the objects in between. > > >> > > >> org.apache.cocoon.util.BufferedOutputStream > > >> secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment > > >> env of > > >> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector > > >> > > >> > > >> redirector of org.apache.cocoon.components.flow.java.ContinuationContext > > > > > > What I was so much concerned about here was the fact of storing the > > > whole environment in the continuation, especially since we have this > > > non-flushing BufferedOutputStream at the end. Is there any point in > > > storing the environment? Do we get anything useful out of it after > > > continueing the continuation? > > > > I committed a fix [1] that limits the data that is stored with the > > ContinuationContext which at least removes the redirector and so the > > BufferedOutputStream instances from the Continuation's memory footprint. > > This should give you a big improvement if the BufferedOutputStream took > > 50% of the memory for you. > > > > Joerg > > > > [1] http://svn.apache.org/viewvc?view=rev&revision=642694 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > ____________________________________________________________________________________ > You rock. That's why Blockbuster's offering you one month of Blockbuster > Total Access, No Cost. > > http://tc.deals.yahoo.com/tc/blockbuster/text5.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
