cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Joseph <>
Subject Re: thought I had fixe it
Date Mon, 24 Oct 2011 17:53:00 GMT
These are excellent ideas Leszek, I sincerely thank you.

Will implement them over the coming days, especially the pipeline one below!


On 10/24/2011 1:40 PM, Leszek Gawron wrote:
> On 2011-10-24 19:22, Paul Joseph wrote:
>> I think you may have the solution--I am indeed putting in a very heavy
>> weight object into the continuation.  Let me go through this code and
>> get back to you with questions if I may.
> I simply remember what used to kill my site and what made up my first 
> commits as cocoon commiter :)
> have fun
> Please DO enable session-bound-continuations! You gain:
> - all continuations simply "vanish" for an expired session
> - there is no single continuations collection
> - you will prevent very strange errors where there is still a 
> continuation that you can invoke but there actually is no user session 
> anymore. Been there, broke that ;)
> Remember that even though you delete heavy object from flowscript your 
> implementation is still not "memory nice". You need to generate 
> VeryLargeObject, render it and then forget it. Imagine 10 users doing 
> it at the same time - kills your server anyway.
> There are two solutions:
>  - some Result object which does not hold all data but actually is an 
> open rowset wrapper. Your jx:template iterates the rowset. The data is 
> fetched from db as you go. Remember to finalize your resources in a 
> cleanup function.
>  - custom generator that queries database directly and emits SAX events.
> Both solutions let you generate results on almost ANY size. One more 
> gotcha: if you generate large responses please mind that by default 
> cocoon buffers the whole response before it's streamed to client (just 
> in case an exception throws in the middle it can send a nice HTTP 500 
> instead of data broken in the middle). This introduces a momory strain 
> on the server and a significant response delay (data is not being sent 
> to client until it's fully generated).
> If you are willing to accept inferior error handling you can disable 
> this buffering for memory intensive pipelines (outputBufferSize):
>> <map:pipeline>
>> <map:parameter name="outputBufferSize" value="0"/>
>> <map:act type="set-header">
>> <map:parameter name="Expires" value="-1"/>
>> <map:parameter name="Cache-Control" value="no-cache"/>
>> <map:parameter name="Pragma" value="no-cache"/>
>> </map:act>
>> <map:match pattern="view/*.jx">
>> <map:generate type="jx" src="view/{1}.jx"/>
>> <map:transform src="stylesheets/prefixes.xsl"/>
>> <map:serialize type="xml"/>
>> </map:match>
>> <map:match pattern="text-view/*.jx">
>> <map:generate type="jx" src="view/{1}.jx"/>
>> <map:serialize type="text"/>
>> </map:match>
>> <map:match pattern="">
>> <map:generate type="coupons"/>
>> <map:serialize type="xml"/>
>> </map:match>
>> <map:match pattern="*.do">
>> <map:call function="{1}"/>
>> </map:match>
>> </map:pipeline>
>     lg

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

View raw message