cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From footh <>
Subject Re: Javaflow - major memory issue: more info
Date Tue, 25 Mar 2008 00:47:34 GMT
Thanks for the reply.  Yea, I'm not too worried about continuation expiry parameter although
like to experiment with shrinking it.

I think you mean sendPage vs sendPageAndWait?  I can't find sendPageAndContinue.  Anyway,
those methods have exactly the same code.

Let me try to explain my case more clearly.  I have a main application with a flow that sets
values required for all pages (mainly in the header, footer, etc).  Then I have a sub-application
that uses the same header, footer, etc. so it needs the same variables set in the main flow.
it also requires its own flow to do some specific logic.

So, in the sitemap for this sub-application, any *.html file goes through the main flow. 
the sendPage method in the main flow changes the uri to something like *  This hits
pipeline that calls the entry method in the flow for the sub-application.  The sendPage in
method then sends the page to a pipeline that aggregates, transforms and serializes.

My objective behind this is to create an inheritance pattern where the sub-application inherits
the logic from the main application.  But apparently this doesn't work based on the profiling
done.  After two sendPage calls, the memory skyrockets and doesn't clean up well.

I have some ideas of how to do things differently but I prefer the this way as it seems more

--- Torsten Curdt <> wrote:

> On Mar 20, 2008, at 20:14, footh wrote:
> > So, it appears that the continuations eventually clean up nicely.   
> > Of course, a constant load
> > would  kill the system as the continuation clean-up is too slow to  
> > keep up.  Two things to note:
> >
> > 1) The expiry parameter in cocoon.xconf did not work.  It was always  
> > 10 minutes no matter what I
> > set it to.
> I remember that was reported before. Should be an easy fix.
> > 2) The bottom paragraph of this page:
> > states that when using the sendPage method, no continuation is  
> > created and memory resources are
> > not used.  This does not seem to be the case as my test case uses a  
> > one-line flow with a sendPage
> > call.
> Did you check the SendPage vs the SendPageAndContinue implementation?
> BTW: What version are you using?
> > Back to my specific case, I then went to test my full-blown  
> > application.  After running a series
> > of tests similar to the one described above, I discovered an area  
> > that appears to be a problem.  I
> > have a main application that uses a "primary" javaflow, and a sub- 
> > application of the main app that
> > needs the general logic in the primary flow and then its own logic  
> > in its own flow.  So, it runs
> > through two javaflows and thus two sendPage calls.
> Not sure I get that ...I remember the limitation of javaflow not  
> behaving if you call a sub pipeline with another javaflow as the  
> continuation is (still) saved in a per-thread context.
> >  To make a long story short, this seemed to
> > cause a memory leak.  Running just the main flow seemed ok, running  
> > just the sub-flow worked ok as
> > well (there appeared to be a bit of a leak, but inconclusive).   
> > However, running a page through
> > both flows showed a clear loss of memory.  The continuations did not  
> > clean up.
> >
> > So, this could very well be the source of my problems.  Based on  
> > note 2) above, I must've figured
> > this would be OK due since sendPage supposedly doesn't have a large  
> > memory footprint.  However, it
> > appears to cause a problem based on my tests.  I'm hoping the  
> > experts can chime in here:  is this
> > as bad an idea as it appears to be (running one page through  
> > multiple flows)?
> Could you give an example here? I am still not sure what you mean  
> exactly by running through two flows.
> Surely what is needed to make this all better and safer in a high load  
> environment is to limit the max number of continuations and not just  
> rely on the time based clean up.
> cheers
> --
> Torsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message