Hi Alok,
Thank you for reviewing the document. Please see my response inline.
On 06/11/10 05:10 PM, Alok Aggarwal wrote:
Hi Karen,
On Fri, 28 May 2010, Karen Tung wrote:
Hi,
The draft install engine design doc is ready for review.
I pushed the doc to the caiman-docs repo. You can
find them under the install_engine directory in
ssh://[email protected]/hg/caiman/caiman-docs
If you don't want to clone the gate, you can also access
the file directly here:
http://cvs.opensolaris.org/source/xref/caiman/caiman-docs/install_engine
I just have a few questions -
Section 6.4.2 - Just to be sure, an exception raised during
the execution of a checkpoint in a thread will be bubbled
up all the way to the application. Correct?
Yes, it will.
My response to Sue's comment had more information about this.
Basically, there will be an exception class called
CheckpointExecError, and it will have 2 attributes. One of the attribute
is the name of the checkpoint that thrown the exception.
The other is the exception that's raised by the checkpoint.
How does the engine determine if a checkpoint failed in
it's execution? Is it implying that if a checkpoint
encounters sort of a soft error, it should not raise an
Exception?
Anytime a checkpoint raised an exception, the engine assumes
that it failed. So, if it is a soft error, it should not raise an
exception.
Maybe it can log the soft error?
Section 7.4.1 Is there any way to over-ride the check
for (2)? For DC, I can see how this can be useful for
debugging purposes -- many times if I want DC to pick
up my version of a specific finalizer/checkpoint, I
just change the path for it and resume for it.
I don't think you need to have an over-ride to the rule 2
in section 7.4.1 to make the case you had above work.
For example,
- Run 1 of DC, you executed A, B, C, D successfully.
- Then, you point C to a different checkpoint.
- Run 2, you can resume from C. Rule 2 in section 7.4.1 just
prevents you on resuming from checkpoint D, because C
is changed.
Section 9 In the case of DC, we have to sets of logs, each
of which log a different level of the messages. After the
engine has initialized the logger, I'm assuming the application
can still addHandler()s to that logger with varying log levels.
Say, the application adds two log destinations.
When the logger is initialized by the engine, a default log will
be created by the InstallLogger class.
If we want to have the DC log to console, simple_log and detailed_log
like we do today, then, you add 3 log handlers to the logger.
DC would interact with the logger directly. It does not need to
go through the engine.
In which of those two logs do the messages from the engine
end up?
Engine will generate 2 types of messages.
Debugging messages will be generated at the log level DEBUG.
Error messages will be generated at the log level ERROR or above.
So, depending on how you set the log level for the log handlers,
the messages will appear accordingly.
Thanks you again for doing the review.
--Karen
Section 11 This answers my question about exceptions being
bubbled up.
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
