cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 15368] - [PATCH] Expire Continuations
Date Tue, 17 Dec 2002 18:46:28 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15368>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15368

[PATCH] Expire Continuations





------- Additional Comments From michaelm@fztig938.bank.dresdner.net  2002-12-17 18:46 -------
> I think the runtime complexity of the code can be substantially lowered if we
> assume that all the continuations have the same expiration period, which 
> cannot be changed on a per-continuation basis.

I assume you mean by this that the timeToLive for each continuation does not 
get reset whenever an continuation is accessed. That is, lastAccessTime becomes 
irrelevant??

If thats the case then yes I agree, the runtime complexity would 
be "substantially lowered". No problem I can modify the patch to implement 
these changes you suggest. Would only be a small change :). Of course you would 
lose the notion of "atomic subtrees" with this.

[...]

> Another thing I'd like to ask about this patch is whether we can have the
> scheduler be woken up on demand. Since we use a sorted list to store
> continuations based on their expiration time, and no new continuations can be
> inserted at the front of the list, we know exactly when the next continuation 
> is going to expire. We don't need to wait 30 minutes to have the scheduler
> wake up and expire the continuations. Can we tell the scheduler at runtime
> when to wake up?

Since the expiration time is now constant, then the above method you mention 
becomes feasible. However if we want expire each contination individually, we 
wont strictly need the scheduler (or the entries in xconf). We will require an 
expire thread to sleep variable amounts of time as determined each time we 
expire a continuation from the experiations set. 

This would be a significant change. Is there a substantial benefit to expiring 
each continuation individually over having a periodic clean up of expired 
continuations??

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message