Re: Expire Continuations Patch[15368] submitted
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: > > > > > > > >18 > >18 > > > > > > > >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: [EMAIL PROTECTED] > >For additional commands, email: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Expire Continuations Patch[15368] submitted
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: 18 18 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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: 18 18 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
