Meeting minutes.  ESD Exceptions Design/Requirements Review   Sept 12, 2002

Ronm:  You can log text in addition to exceptions. (in response to question my Mike).

Bob: There are on the order of 8000 exceptions in SLC. But, we should have fewer in the new system because the naming (and use) of them is more general in that any given exception can be used in many different ways.

Greg said: You correctly stated that there is no exception hierarchy.  But, if we break except.idl up into different IDL files for different modules, we would be able to catch different types of exceptions.  We would have different IDL files, one each for different modules.  Can't catch exceptions of a specific type now because they are all together.  Want to be able to catch by module.  Have a number at the same level.  Wants to trap exceptions of a specific type.  Breaking it up by module would allow us to do this.  Have a number of parallel classes.  Breaking up into multiple  IDL files might be a first step before we write an hierarchical exception generator which reads input from an Oracle database.  (Ronm wonders if it's better to use Berkeley DB instead (or some other free db), so that sites that share our code won't be required to have Oracle.).  The multiple IDL files could be done sooner, with the Database later, in Phase II.  Greg says that the generation utility that reads the database and produces include/import files is a perfect XML/XSLT application and wonders if someone has already done it.  Bob looked at CORBA 3.0 and sees no enhancements to the exceptions there (so moving away from IDL exceptions is probably a good idea for us).   The concern was raised  wondering if Streaming into an Any would be a problem... that the IDL exceptions give us the helper functions for streaming into the any and that's why we need IDL exceptions... (that, it turns out, is not true in the current code).. The Exception transporter gives us the way to stream into the any.  The current  code doesn't use exception helper functions, it uses ExceptionTransporter helper functions instead.  Bob says, that if we use Notify, then it's not a problem anyway because you can use structured data.

Mike/Greg: Provide a way to override the CMLOG time stamp when logging the message.  The application should be able to provide a timestamp when logging the messages.  Greg suggested an overloaded log method where the user provides the timestamp.   Mike asked in which base the timestamp will be. Ronm said that in phase II, the format of that provided time stamp should use a general purpose timestamp class.  Also provide a way to override the host field.  Provide a way to Override all the tags.   Greg suggest subclassing the class instead of overriding. because you really want to forward the exceptions where as this class logs methods.

Ronm: There is a way to throw and log at one time (one line of code). (in response to question by Bob).

Greg:  We didn't try to do exception chaining like Ralph did.  (in response to question by RonC).  We did it another way.

Nancy: Should provide a way to indicate "don't log at the lowest level".  If I'm a client, and call a server, want to tell the server not to log.   The client should be able to set this  'no log' setting.  Like CAMIO, as part of the call from the high level,  it  tells the low level remote code not to log error messages.

Ronm: No throttling in this release (in response to question by Mike).  There will be a future requirements review which could consider throttling.  It might be an application problem (ronm).

Ronm: We are transmitting text, not error codes. I wonder if Greg is thinking that we might transmit the IDL exception inside the any instead to save bandwidth.  Would sending an object really save any bandwidth? I suspect not.

Mike: Provide cached backup storage in Err class so that when Err can 't connect to the Event service, messages are not lost.  The messages would be saved up to some limit amount of storage (bytes) and then transmitted when the connection is re-established.  Have the  limit be specified by user.  Consider this for Part of next release after we get some operational experience with this system (Greg).

Greg:  Event Service will be a persistent server.  So it will restart itself.

Jingchen suggested that there be a way that when you log a message, you tell it if you want DEV or PROD (the destination of the message... i.e. which event service gets used).  I wonder if we should provide a way to overload the log method to specify which logger gets used too?

Bob, when we were discussing performance, noted that you can add 2ms per hop for a general idea of how long it will take to log messages.

Greg, noted that we haven't tried running multiple event services yet.  I think he was wondering if there are any restrictions that Iona imposed that would prevent running multiple services.  We should test this!

Jingchen asked if there is some limit on the number of connections to the event services.  RonM said he doesn't think it will be a problem.  It would be good to investigate this and have an answer.

RonC asked if using IDL is a good idea because of the limitations. Is there a different way to do it?  Greg pointed out that Oracle DB is that better way in a future release.  We'll extract oracle tables straight to java/c++ include files (in effect writing our own IDL compiler).  Using IDL now doesn't close down those paths.  Implementation will be done in the Err class and downstream and be transparent to the applications. This would provide exception chaining and hierarchy.

RonC asked about supporting complex data structures like George did.  RonM said that we are putting a complex data structure (the transporter) inside the any.  RonM also noted that we didn't put fields in the IDL exceptions so that programmer's don't have to remember what fields to set.

Mike asked what platforms clients can run on.  The answer is any platform that supports Java 1.3 and 1.4.  For C++ it needs to be an Iona supported/gcc platform.  The ioc's are probably not supported at this time.  (But, there is a version of Orbacus for embedded systems called OrbacusE which would be a possibility for the future).

Check Big Err, little err names in C++ API.  (Ronm to do this).

The include filename is wrong in C++ API (Ken Underwood).  Should be except.h, not err.h. (RonM to fix this).

Jingchen had a concern about sharing this critical and large except.idl file.  We could have a script which would check what you added or changed for validity.  For example, checking that what you added doesn't already exist.

RonM suggested dependencies in other packages on except.idl.  Greg/Bob/Mike said that's not needed.