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 08:27:49 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 ovidiu@apache.org  2002-12-17 08:27 -------
Excellent work, Michael, thanks!

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.

With this assumption in mind, we observe that in a tree of continuations the
parent continuation will expire first. We can also observe that in a list of
sibling continuations, the expiration time increases from left to right
(assuming the sibling continuations are added always at the end of the list).
The last observation is not as important as the first one, which we can use to
optimize the algorithm you propose for continuation expiration.

With this simplification, the new removeContinuation() method in
ContinuationManagerImpl becomes:

public void removeContinuation(WebContinuation wk)
{
    idToWebCont.remove(wk.getId());
    expirations.remove(wk);
    wk.invalidate();
}


The code above requires a new method invalidate() in WebContinuation:

public void invalidate()
{
    for (int i = 0, size = children.size(); i < size; i++) {
        WebContinuation wkchild = (WebContinuation)children.get(i);
        wkchild.parentContinuation = null;
    }
}

The WebContinuation class could be even further simplified by removing the
timeToLive instance variable.

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?

Thanks,
Ovidiu

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


Mime
View raw message