cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: Continuations consume ram, possible solutions?
Date Mon, 31 Jul 2006 12:08:05 GMT
Ard Schrijvers wrote:
>> The second solution is very wise, and IIRC you already have something
>> implemented. Using named continuations mean that every 
>> continuation have
>> a "name", and there can only one continuation tree with a 
>> given name in
>> the http session. This way, if i have a certain search page that
>> everybody uses, when the user makes a search the continuation 
>> is created
>> and eventually its subcontinuations, but when the user goeas away from
>> the page and then returns to the search page, a new continuation with
>> the same name is created, which will replace the old tree, so freeing
>> the ram. This way, if a typical site pattern is to do 10 searches,
>> instead of having 10 continuation trees in RAM until they expire, we
>> have only one.
>> This would not only solve "first continuations" but free the entire
>> continuation trees. We could ease it a bit using the entry 
>> function name
>> as the continuation name, and having a "singleton" notation somewhere
>> (cocoon.setSingletonContinuations()) to mark those scripts that uses
>> single named continuations.
> We implemented this idea recently indeed. We define wether a continuation is "unique"
in its type, we give a continuation a name, and then, when it is doubled (same name), we delete
the previous one. Though, we ran into a bug regarding this implementation recently, and I
still don't know how to solve it: 
> I set the continuation to have unique=true and set its name always as follows: 
> if I have a flow function in /explorer/doclisting/flow.js and the function is called
"doclisting", my continuation name would become: explorer.doclisting.flow.js.doclisting, to
be sure that it is unique. If it is tied to a specific session, I add the hashcode of the
> When somebody click on another folder, a new doclisting is created, and the continuation
has the same name, so the previous one can be deleted. But, when using AJAX kind of things,
we happen to use the same flow function for clicking on a document as on a folder, but does
not update all forms on the browser. But part of the forms now have continuations that are
> I think this approach again can only solve some of the memory/continuations problems
if you really know what you are doing, but it is very error prone. Also solving bugs like
described above is very hard when you do not really know what is behing the idea of unique
continuations. I really doubt wether we want to go that way.

Why do you want continuations to have it's name automatically generated?

cocoon.sendPageAndWait( view, bizData, continuationName )?

This way user could choose which continuations would automatically kill 

>> The third option aims to solve the common situation of having a flow
>> that initializes some variables, sends a form or a page (creating a
>> continuation) and then waits for the user to click on a 
>> button, that 90%
>> of time never gets pushed. This is quite common in aggregated 
>> pages with
>> boxes or something similar.
>> The idea here is NOT saving anything in the continuation, instead when
>> the continuation is recalled, the function is executed again from the
>> beginning, but skipping the first sendPage (since that page 
>> has already
>> been sent). This way we don't have any serialization issue, 
>> the form is
>> created, displayed and then garbage collected, and recreated when the
>> user clicks the button, not displayed again since the first 
>> sendPage is
>> skipped, but only populated from the request.
>> This is maybe the simplest one to implement, but is quite 
>> untidy because
>> if the code in the first lines execute something heavy or 
>> some business
>> logic, it could not be clear why it's getting executed twice. 
>> But since
>> it's aimed to solve the problem of simple forms generated many times
>> (like login boxes, polls, subscribe here boxes and so on), it's highly
>> possible that the first lines of the flow are simply instantiating a
>> bean or a document, creating a form, doing some binding and displaying
>> it, and if it's really a box aside the pages of the side that code is
>> already executed at every get.
> This might be a lightweight sollution indeed. I suppose that you can tell the continuation
then that it is a lightweight or something? For example, lightSendPageAndWait. I think implementing
it in the original sendPageAndWait/continuation might not be backwardscompatible: the implementation
could have business logic before the continuation that actually stores something, that would
be called again in the lightweight continuation. 
>> Do you (plural, rest of cocoon community) have any other idea about
>> this? "Continuation pollution" is actually a problem in flow
>> implementations.

In this scenario why use continuations in first place?

I have another proposition: currently if a continuation is valid the 
whole tree down to the root is kept. Why not implement a continuation 
that eats his own tail? I mean if new continuation is generated it's 
parent gets invalidated and removed.

This means of course that users will not be allowed to hit back button 
but this is not the issue for database intensive web applications (which 
would produce weird behaviour anyhow).

Some users were already asking for some automatic invalidation of 
continuations. We could have two things done at the same time.

Leszek Gawron                            
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message