You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Melhem <mi...@fztig938.bank.dresdner.net> on 2002/12/16 13:46:17 UTC
Expire Continuations Patch[15368] submitted
Hi all,
FYI, bugzilla Patch [Bug 1538] implements "Expire Continuations" using
the cornerstone scheduler to periodically (as defined in the xconf) clean
up expired flow continuations.
I decided to use the cornerstone-scheduler because the avalon-monitor was
not appropriate, and I wanted to use a standard avalon component (and
not have to write my own scheduler;).
The continuations "short-hand" in the roles file has been renamed
continuations-manager because it is infact ContiustionsManagerImp that
is being defined here. So xconf becomes:
<continuations-manager logger="flow" time-to-live="3600000">
<expirations-check type="periodic">
<offset>180000</offset>
<period>180000</period>
</expirations-check>
</continuations-manager>
The above configures the continuations-manager, setting "1 hour" as the
default time-to-live for contunuations, and setting 30 mins as the interval
between expire checks. Note: all durations are specified in milliseconds.
So, If someone can review this patch (and perhaps apply it) then that
would be great!! ;)
Points Of Interest:-
1. Im using what is called atomic-subtree algorithm to expire the
continuations. (See
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103893658515510&w=2)
for explanation of this). It wouldnt be difficult to configure the
manager to use a different expire algorithm (if that was deemed necessary).
2. Currently The latest cut of cornerstone does not appear to work with the
lastest excalibur-thread*.jars. Im chasing this up to get this fixed.
3. As far I can tell the current ECM in Cocoon does not handle non-component
classes (such as the latest cornerstone-scheduler). I have worked around this,
but this issue needs to be addressed. Perhaps we need to update the ECM
version in Cocoon?
Best Regards,
Michael Melhem
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Expire Continuations Patch[15368] submitted
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Mon, Dec 16, 2002 at 09:40:59AM -0800, Ovidiu Predescu wrote:
> Great job, Michael! I'll take a look at it and check it in
> appropriately.
No Problem :)
>
> One thing I think we can change to make things simpler is to disallow
> customizing the time-to-live on a continuation instance basis. This
> would force continuations to be expired starting from the top of the
> tree, making the expiring algorithm a lot simpler. Changing TTL on a
> continuation basis does not seem to give us a big benefit compared to
> the (computational) complexity of the algorithm.
It should be easy to modify expire strategy as required.
>
> I'll check out your implementation in more detail and see what would be
> the implications of the above.
Ok, thanks for taking the time.
Best Regards,
Michael Melhem
>
> Best regards,
> Ovidiu
>
> On Monday, Dec 16, 2002, at 04:46 US/Pacific, Michael Melhem wrote:
>
> >Hi all,
> >
> >FYI, bugzilla Patch [Bug 1538] implements "Expire Continuations" using
> >the cornerstone scheduler to periodically (as defined in the xconf)
> >clean
> >up expired flow continuations.
> >
> >I decided to use the cornerstone-scheduler because the avalon-monitor
> >was
> >not appropriate, and I wanted to use a standard avalon component (and
> >not have to write my own scheduler;).
> >
> >The continuations "short-hand" in the roles file has been renamed
> >continuations-manager because it is infact ContiustionsManagerImp that
> >is being defined here. So xconf becomes:
> >
> ><continuations-manager logger="flow" time-to-live="3600000">
> > <expirations-check type="periodic">
> > <offset>180000</offset>
> > <period>180000</period>
> > </expirations-check>
> ></continuations-manager>
> >
> >The above configures the continuations-manager, setting "1 hour" as the
> >default time-to-live for contunuations, and setting 30 mins as the
> >interval
> >between expire checks. Note: all durations are specified in
> >milliseconds.
> >
> >So, If someone can review this patch (and perhaps apply it) then that
> >would be great!! ;)
> >
> >
> >Points Of Interest:-
> >
> >1. Im using what is called atomic-subtree algorithm to expire the
> >continuations. (See
> >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103893658515510&w=2)
> >for explanation of this). It wouldnt be difficult to configure the
> >manager to use a different expire algorithm (if that was deemed
> >necessary).
> >
> >2. Currently The latest cut of cornerstone does not appear to work
> >with the
> >lastest excalibur-thread*.jars. Im chasing this up to get this fixed.
> >
> >3. As far I can tell the current ECM in Cocoon does not handle
> >non-component
> >classes (such as the latest cornerstone-scheduler). I have worked
> >around this,
> >but this issue needs to be addressed. Perhaps we need to update the ECM
> >version in Cocoon?
> >
> >Best Regards,
> >Michael Melhem
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> >For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Expire Continuations Patch[15368] submitted
Posted by Ovidiu Predescu <ov...@apache.org>.
Great job, Michael! I'll take a look at it and check it in
appropriately.
One thing I think we can change to make things simpler is to disallow
customizing the time-to-live on a continuation instance basis. This
would force continuations to be expired starting from the top of the
tree, making the expiring algorithm a lot simpler. Changing TTL on a
continuation basis does not seem to give us a big benefit compared to
the (computational) complexity of the algorithm.
I'll check out your implementation in more detail and see what would be
the implications of the above.
Best regards,
Ovidiu
On Monday, Dec 16, 2002, at 04:46 US/Pacific, Michael Melhem wrote:
> Hi all,
>
> FYI, bugzilla Patch [Bug 1538] implements "Expire Continuations" using
> the cornerstone scheduler to periodically (as defined in the xconf)
> clean
> up expired flow continuations.
>
> I decided to use the cornerstone-scheduler because the avalon-monitor
> was
> not appropriate, and I wanted to use a standard avalon component (and
> not have to write my own scheduler;).
>
> The continuations "short-hand" in the roles file has been renamed
> continuations-manager because it is infact ContiustionsManagerImp that
> is being defined here. So xconf becomes:
>
> <continuations-manager logger="flow" time-to-live="3600000">
> <expirations-check type="periodic">
> <offset>180000</offset>
> <period>180000</period>
> </expirations-check>
> </continuations-manager>
>
> The above configures the continuations-manager, setting "1 hour" as the
> default time-to-live for contunuations, and setting 30 mins as the
> interval
> between expire checks. Note: all durations are specified in
> milliseconds.
>
> So, If someone can review this patch (and perhaps apply it) then that
> would be great!! ;)
>
>
> Points Of Interest:-
>
> 1. Im using what is called atomic-subtree algorithm to expire the
> continuations. (See
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103893658515510&w=2)
> for explanation of this). It wouldnt be difficult to configure the
> manager to use a different expire algorithm (if that was deemed
> necessary).
>
> 2. Currently The latest cut of cornerstone does not appear to work
> with the
> lastest excalibur-thread*.jars. Im chasing this up to get this fixed.
>
> 3. As far I can tell the current ECM in Cocoon does not handle
> non-component
> classes (such as the latest cornerstone-scheduler). I have worked
> around this,
> but this issue needs to be addressed. Perhaps we need to update the ECM
> version in Cocoon?
>
> Best Regards,
> Michael Melhem
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org