cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Joseph <pjos...@gmail.com>
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!

brgds
Paul

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="listCoupons.do">
>> <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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message