You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by footh <fo...@yahoo.com> on 2008/04/01 19:00:21 UTC
Re: Javaflow - major memory issue
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 <jo...@gmx.de> 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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
____________________________________________________________________________________
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Javaflow - major memory issue
Posted by Joerg Heinicke <jo...@gmx.de>.
footh <footh <at> yahoo.com> writes:
> Ok, I applied all the changes in order. Since some changes affect the same
> class, I'm assuming the latter change contains any changes from a previous
> revision.
I don't know how exactly you mean this, but one *change* does definitely not
include the former changes since it is always a diff against the latest
revision. If I were you I would just grab the latest revisions of the mentioned
files. Those ones also have all the former changes. There should be no
incompatibility introduced between 2.1.10 and latest code in the 2.1 SVN branch.
> I'm getting this error when building:
>
> \src\java\org\apache\cocoon\components
> \flow\ContinuationsManagerImpl.java:538: clone() has protected access in
> java.lang.Object
> clonedRootWebContinuations.add(rootContinuation.clone());
>
> Did I mess up applying the changes? Have you successfully built the revised
> version?
That's more or less my fault. I made another commit where I did not separate
clearly the issues and part of the fixes you are actually interested in got into
that commit. It's http://svn.apache.org/viewvc?rev=643294&view=rev, but what you
actually only need from this commit are part of the changes to WebContinuation:
add Cloneable to its implements list, get the two methods toString() and
clone(). Leave the rest just as it is if you are not interested in Flowscript.
Hope this helps,
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Javaflow - major memory issue
Posted by footh <fo...@yahoo.com>.
Ok, I applied all the changes in order. Since some changes affect the same class, I'm assuming
the latter change contains any changes from a previous revision.
I'm getting this error when building:
\src\java\org\apache\cocoon\components
\flow\ContinuationsManagerImpl.java:538: clone() has protected access in java.lang.Object
clonedRootWebContinuations.add(rootContinuation.clone());
Did I mess up applying the changes? Have you successfully built the revised version?
Concerning your other question, I've waited as long as 30 minutes or more to see if the memory
would free up but it did not.
--- Joerg Heinicke <jo...@gmx.de> wrote:
> On 02.04.2008 12:24, footh wrote:
>
> > Yes, I only applied 642694 as it was the only the link in your previous post. I altered the
> three
> > files:
> >
> > AbstractContinuable.java
> > Continuation.java
> > ContinuationContext.java
> >
> > to the files in the links and rebuilt Cocoon, only switching out the javaflow library on my
> test
> > instance. Nothing else changed in my test environment from the calculable results I got last
> > time. I'm using YourKit profiler and the Apache JMeter testing tool with debugging turned
> off.
> >
> > Should I have applied all the fixes you described below?
>
> 642694 was supposed to give you the first improvements by limiting the
> continuation's memory footprint. 642756 is a better fix for the same
> problem cleaning up even more. In the latter revision I reverted the
> changes to AbstractContinuable and ContinuationContext and made new
> changes to Continuation and JavaInterpreter (as outlined below in more
> details).
>
> The other fixes are not necessary and I don't know if you would see
> improvements from them. BUT your version of the ContinuationsManagerImpl
> has serious threading issues. Depending on your tests it might happen
> that you shoot the "expired continuations clean up" thread by creating
> new continuation at the same time (leads to
> ConcurrentModificationException). Again for more details read below.
>
> COCOON-2109 solves another problem with cleaning up the expired
> continuations. If this one has effects depends on your actual tests. And
> again for more details read below :)
>
> The best is to have all fixes, yes. Otherwise a certain test run could
> just have "bad luck" and does not show the improvements. Also do you
> wait exactly 10 minutes? That's only the time when the first
> continuations get invalidated, so the clean up thread had hardly any
> chance to jump in. Do you have better results waiting let's say 15 or 20
> minutes?
>
> Joerg
>
> > --- Joerg Heinicke <jo...@gmx.de> wrote:
> >
> >> On 01.04.2008 18:52, footh wrote:
> >>
> >>> 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.
> >> That's no good news :( And I can't see how this should be possible.
> >>
> >> Which changes exactly did you apply? Only rev 642694 [1]? The actual two
> >> files changed are ContinuationContext (added method onSuspend()) and
> >> AbstractContinuable (calling context.onSuspend() right before
> >> Continuation.suspend()). The method only nulls out some values, so I
> >> can't see how this should have worsen the situation. Both files had not
> >> changed between 2.1.10 and 2.1.11, so this can neither be a reason.
> >>
> >> Second, this was only the first approach. After Torsten's review I did a
> >> more "brave" approach setting the complete context to null before the
> >> continuation gets suspended [2]. Here I reverted the above 2 changes to
> >> AbstractContiuable and ContinuationsContext. The fix went into
> >> Continuation (storing functionName and setting context to null in
> >> suspend()) and JavaInterpreter (instantiating Continuation with
> >> functionName and retrieving it from there later on). Again I can't see
> >> how this should have worsen the situation. Both files had again not
> >> changed since 2.1.10.
> >>
> >> Then in order to fix COCOON-2109 [3] I applied another fix [4]. If that
> >> one helps you at all pretty much depends on whether you access old
> >> continuations or not (when using a wizard you not only go forward along
> >> the expected path (page 1, page 2, etc.) but also go back).
> >>
> >> The last important fix is for synchronization issues in
> >> ContinuationsManagerImpl [5]. This definitely has some impact, it's
> >> usually unlikely that fixing synchronization improves performance. If
> >> you don't have this fix I can imagine that the situation is as bad as
> >> you describe it for the following reasons: If something creates a new
> >> continuation while the clean up thread for removing expired
> >> continuations is active it kicks the latter one with a
> >> ConcurrentModificationException - and the clean up just stops. This
> >> would mean though that it was just bad luck in your new test.
> >>
> >> I don't know how exactly you profiled your system. You should definitely
> >> NOT run on debug log level. I fixed the synchronization issues in favor
> >> of the debug log level: There are no longer two sets maintained but the
> >> second set (which was for debugging purposes only) gets recreated "on
> >> demand", i.e. debug log level, which locks the manager for that time.
> >> But it should improve the overall situation though.
> >>
> >> Joerg
> >>
> >> [1] http://svn.apache.org/viewvc?view=rev&revision=642694
> >> [2] http://svn.apache.org/viewvc?view=rev&revision=642756
> >> [3] https://issues.apache.org/jira/browse/COCOON-2109
> >> [4] http://svn.apache.org/viewvc?view=rev&revision=642843
> >> [5] http://svn.apache.org/viewvc?view=rev&revision=643295
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
____________________________________________________________________________________
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Javaflow - major memory issue
Posted by Joerg Heinicke <jo...@gmx.de>.
On 02.04.2008 12:24, footh wrote:
> Yes, I only applied 642694 as it was the only the link in your previous post. I altered the three
> files:
>
> AbstractContinuable.java
> Continuation.java
> ContinuationContext.java
>
> to the files in the links and rebuilt Cocoon, only switching out the javaflow library on my test
> instance. Nothing else changed in my test environment from the calculable results I got last
> time. I'm using YourKit profiler and the Apache JMeter testing tool with debugging turned off.
>
> Should I have applied all the fixes you described below?
642694 was supposed to give you the first improvements by limiting the
continuation's memory footprint. 642756 is a better fix for the same
problem cleaning up even more. In the latter revision I reverted the
changes to AbstractContinuable and ContinuationContext and made new
changes to Continuation and JavaInterpreter (as outlined below in more
details).
The other fixes are not necessary and I don't know if you would see
improvements from them. BUT your version of the ContinuationsManagerImpl
has serious threading issues. Depending on your tests it might happen
that you shoot the "expired continuations clean up" thread by creating
new continuation at the same time (leads to
ConcurrentModificationException). Again for more details read below.
COCOON-2109 solves another problem with cleaning up the expired
continuations. If this one has effects depends on your actual tests. And
again for more details read below :)
The best is to have all fixes, yes. Otherwise a certain test run could
just have "bad luck" and does not show the improvements. Also do you
wait exactly 10 minutes? That's only the time when the first
continuations get invalidated, so the clean up thread had hardly any
chance to jump in. Do you have better results waiting let's say 15 or 20
minutes?
Joerg
> --- Joerg Heinicke <jo...@gmx.de> wrote:
>
>> On 01.04.2008 18:52, footh wrote:
>>
>>> 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.
>> That's no good news :( And I can't see how this should be possible.
>>
>> Which changes exactly did you apply? Only rev 642694 [1]? The actual two
>> files changed are ContinuationContext (added method onSuspend()) and
>> AbstractContinuable (calling context.onSuspend() right before
>> Continuation.suspend()). The method only nulls out some values, so I
>> can't see how this should have worsen the situation. Both files had not
>> changed between 2.1.10 and 2.1.11, so this can neither be a reason.
>>
>> Second, this was only the first approach. After Torsten's review I did a
>> more "brave" approach setting the complete context to null before the
>> continuation gets suspended [2]. Here I reverted the above 2 changes to
>> AbstractContiuable and ContinuationsContext. The fix went into
>> Continuation (storing functionName and setting context to null in
>> suspend()) and JavaInterpreter (instantiating Continuation with
>> functionName and retrieving it from there later on). Again I can't see
>> how this should have worsen the situation. Both files had again not
>> changed since 2.1.10.
>>
>> Then in order to fix COCOON-2109 [3] I applied another fix [4]. If that
>> one helps you at all pretty much depends on whether you access old
>> continuations or not (when using a wizard you not only go forward along
>> the expected path (page 1, page 2, etc.) but also go back).
>>
>> The last important fix is for synchronization issues in
>> ContinuationsManagerImpl [5]. This definitely has some impact, it's
>> usually unlikely that fixing synchronization improves performance. If
>> you don't have this fix I can imagine that the situation is as bad as
>> you describe it for the following reasons: If something creates a new
>> continuation while the clean up thread for removing expired
>> continuations is active it kicks the latter one with a
>> ConcurrentModificationException - and the clean up just stops. This
>> would mean though that it was just bad luck in your new test.
>>
>> I don't know how exactly you profiled your system. You should definitely
>> NOT run on debug log level. I fixed the synchronization issues in favor
>> of the debug log level: There are no longer two sets maintained but the
>> second set (which was for debugging purposes only) gets recreated "on
>> demand", i.e. debug log level, which locks the manager for that time.
>> But it should improve the overall situation though.
>>
>> Joerg
>>
>> [1] http://svn.apache.org/viewvc?view=rev&revision=642694
>> [2] http://svn.apache.org/viewvc?view=rev&revision=642756
>> [3] https://issues.apache.org/jira/browse/COCOON-2109
>> [4] http://svn.apache.org/viewvc?view=rev&revision=642843
>> [5] http://svn.apache.org/viewvc?view=rev&revision=643295
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Javaflow - major memory issue
Posted by footh <fo...@yahoo.com>.
Yes, I only applied 642694 as it was the only the link in your previous post. I altered the three
files:
AbstractContinuable.java
Continuation.java
ContinuationContext.java
to the files in the links and rebuilt Cocoon, only switching out the javaflow library on my test
instance. Nothing else changed in my test environment from the calculable results I got last
time. I'm using YourKit profiler and the Apache JMeter testing tool with debugging turned off.
Should I have applied all the fixes you described below?
--- Joerg Heinicke <jo...@gmx.de> wrote:
> On 01.04.2008 18:52, footh wrote:
>
> > 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.
>
> That's no good news :( And I can't see how this should be possible.
>
> Which changes exactly did you apply? Only rev 642694 [1]? The actual two
> files changed are ContinuationContext (added method onSuspend()) and
> AbstractContinuable (calling context.onSuspend() right before
> Continuation.suspend()). The method only nulls out some values, so I
> can't see how this should have worsen the situation. Both files had not
> changed between 2.1.10 and 2.1.11, so this can neither be a reason.
>
> Second, this was only the first approach. After Torsten's review I did a
> more "brave" approach setting the complete context to null before the
> continuation gets suspended [2]. Here I reverted the above 2 changes to
> AbstractContiuable and ContinuationsContext. The fix went into
> Continuation (storing functionName and setting context to null in
> suspend()) and JavaInterpreter (instantiating Continuation with
> functionName and retrieving it from there later on). Again I can't see
> how this should have worsen the situation. Both files had again not
> changed since 2.1.10.
>
> Then in order to fix COCOON-2109 [3] I applied another fix [4]. If that
> one helps you at all pretty much depends on whether you access old
> continuations or not (when using a wizard you not only go forward along
> the expected path (page 1, page 2, etc.) but also go back).
>
> The last important fix is for synchronization issues in
> ContinuationsManagerImpl [5]. This definitely has some impact, it's
> usually unlikely that fixing synchronization improves performance. If
> you don't have this fix I can imagine that the situation is as bad as
> you describe it for the following reasons: If something creates a new
> continuation while the clean up thread for removing expired
> continuations is active it kicks the latter one with a
> ConcurrentModificationException - and the clean up just stops. This
> would mean though that it was just bad luck in your new test.
>
> I don't know how exactly you profiled your system. You should definitely
> NOT run on debug log level. I fixed the synchronization issues in favor
> of the debug log level: There are no longer two sets maintained but the
> second set (which was for debugging purposes only) gets recreated "on
> demand", i.e. debug log level, which locks the manager for that time.
> But it should improve the overall situation though.
>
> Joerg
>
> [1] http://svn.apache.org/viewvc?view=rev&revision=642694
> [2] http://svn.apache.org/viewvc?view=rev&revision=642756
> [3] https://issues.apache.org/jira/browse/COCOON-2109
> [4] http://svn.apache.org/viewvc?view=rev&revision=642843
> [5] http://svn.apache.org/viewvc?view=rev&revision=643295
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
____________________________________________________________________________________
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Javaflow - major memory issue
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.04.2008 18:52, footh wrote:
> 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.
That's no good news :( And I can't see how this should be possible.
Which changes exactly did you apply? Only rev 642694 [1]? The actual two
files changed are ContinuationContext (added method onSuspend()) and
AbstractContinuable (calling context.onSuspend() right before
Continuation.suspend()). The method only nulls out some values, so I
can't see how this should have worsen the situation. Both files had not
changed between 2.1.10 and 2.1.11, so this can neither be a reason.
Second, this was only the first approach. After Torsten's review I did a
more "brave" approach setting the complete context to null before the
continuation gets suspended [2]. Here I reverted the above 2 changes to
AbstractContiuable and ContinuationsContext. The fix went into
Continuation (storing functionName and setting context to null in
suspend()) and JavaInterpreter (instantiating Continuation with
functionName and retrieving it from there later on). Again I can't see
how this should have worsen the situation. Both files had again not
changed since 2.1.10.
Then in order to fix COCOON-2109 [3] I applied another fix [4]. If that
one helps you at all pretty much depends on whether you access old
continuations or not (when using a wizard you not only go forward along
the expected path (page 1, page 2, etc.) but also go back).
The last important fix is for synchronization issues in
ContinuationsManagerImpl [5]. This definitely has some impact, it's
usually unlikely that fixing synchronization improves performance. If
you don't have this fix I can imagine that the situation is as bad as
you describe it for the following reasons: If something creates a new
continuation while the clean up thread for removing expired
continuations is active it kicks the latter one with a
ConcurrentModificationException - and the clean up just stops. This
would mean though that it was just bad luck in your new test.
I don't know how exactly you profiled your system. You should definitely
NOT run on debug log level. I fixed the synchronization issues in favor
of the debug log level: There are no longer two sets maintained but the
second set (which was for debugging purposes only) gets recreated "on
demand", i.e. debug log level, which locks the manager for that time.
But it should improve the overall situation though.
Joerg
[1] http://svn.apache.org/viewvc?view=rev&revision=642694
[2] http://svn.apache.org/viewvc?view=rev&revision=642756
[3] https://issues.apache.org/jira/browse/COCOON-2109
[4] http://svn.apache.org/viewvc?view=rev&revision=642843
[5] http://svn.apache.org/viewvc?view=rev&revision=643295
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Javaflow - major memory issue
Posted by footh <fo...@yahoo.com>.
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 <fo...@yahoo.com> 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 <jo...@gmx.de> 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: users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
> >
> >
>
>
>
> ____________________________________________________________________________________
> 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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
____________________________________________________________________________________
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org