On Mar 25, 2008, at 01:47, footh wrote:
Thanks for the reply. Yea, I'm not too worried about continuation
expiry parameter although I'd
like to experiment with shrinking it.
Yeah ....the problem really is not the expiry parameter. It's more the
need for a maximum kept number of continuations. Thought that had
already been implemented. But I am not sure that really is the problem
here.
I think you mean sendPage vs sendPageAndWait? I can't find
sendPageAndContinue.
Ups ...of course 'sendPageAndWait'
Anyway, both
those methods have exactly the same code.
Not really
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-javaflow/cocoon-javaflow-impl/src/main/java/org/apache/cocoon/components/flow/java/AbstractContinuable.java?view=markup
see the 'Continuation.suspend()'?
Let me try to explain my case more clearly. I have a main
application with a flow that sets some
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. But
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. Then,
the sendPage method in the main flow changes the uri to something
like *.html.xyz. This hits a
pipeline that calls the entry method in the flow for the sub-
application. The sendPage in this
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 I've
done. After two sendPage calls, the memory skyrockets and doesn't
clean up well.
I am really not 100% about the implementation you are
describing ...but it somewhat sounds like you are hitting the current
sub-pipeline restriction of javaflow. (Currently you may not call a
sub pipeline from javaflow that has another javaflow inside) This is
something that would need to be fixed in javaflow itself. Probably not
even be that hard to implement. ...on the other hand if you are just
calling 'sendPage' this *should* not really affect the javaflow
capturing.
Since you are just calling 'sendPage' and are not really using flow
features in the first step I would write an action and see whether
that changes the picture.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
