Alok, I'm not sure that this is an issue.
As we previously discussed, ManifestParser checkpoint would be always run - so DC itself would add this as a checkpoint to run, and then run Engine.execute() such that it stops after executing it. Then DC can look at what came in, do any post-processing/setup, etc. and then resume by calling Engine.execute() which shouldn't ever run MP again since it's already run successfully. I'm not sure that MP should ever need to appear in the list of resume-able checkpoints - since it's always going to be run - has to be to enable the resume mechanism to work, since the snapshots of the DOC are stored at a location relative to the DC work area specified in the manifest (i.e. /rpool/dc). Darren. On 07/14/10 12:04 AM, Alok Aggarwal wrote: > Karen raised an important point during her > review of the DC design spec. > > The spec proposes that the manifest-parser be run > as a checkpoint mainly to provide the ability to > pause at that step (and obviously resume from it). > manifest-parser is highly likely to be the very > first checkpoint that gets run. > > This presents us with two problems - > > a) A chicken-and-egg problem. manifest-parser can't > be executed until the manifest has been parsed. > The manifest can't be parsed until the manifest-parser > has been executed. > > b) If DC is resumed from one of the checkpoints, say, > "ba-init", manifest parser still needs to get > executed prior to resuming from "ba-init". If manifest > parser is executed as a checkpoint and it is one of > the checkpoints that is listed prior to "ba-init", > it won't even get executed. > > These problems could concievably solved by having > manifest-parser not be a checkpoint at all. It can't > be resumed from anyway so it would not be a huge deal; > the manifest data is represented in the volatile tree > that isn't snapshotted. We do however lose the observability > that comes with being able to stop at the manifest parsing > step. > > What do people think about this? > > Alok > _______________________________________________ > caiman-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
