[IGSTK-Developers] logging issues

[Hee-su Kim]

Hi, 

I hope this could be useful for discussing logging.

----------------- from IGSTK requirements and blake_IGSTKMeeting212 ---------------
5.7 Logging Requirements

5.7.1 The IGSTK platform shall contain a general, 
centralized logging capability 
that can be used for all IGSTK components.

5.7.2 The logging capability shall support timestamps
 for the audited information.

5.7.3 The logging capability shall enable logging 
for multiple components concurrently and support auditing into multiple files.

* Should have run-time and compile-time switches 
to adjust logging and validation sensitivity
-----------------------------------------------------------------



< More Requirements or Design Candidates >
------ from http://www.codeproject.com/cpp/loggerservice.asp -----
# Survive a crash of the application(s) being logged.
# Minimise performance impacts on the application(s) being logged. This was especially important because the logging system wasn't going to be a 'debug only' deal. Release versions of our software would also do logging.
# Log, on a per module basis, things that each developer thought was relevant.
# Support Log Levels
# Be able to 'age' a logfile.
# Be an easy retrofit to existing code.
# Limit the size of a log file.

< A Candidate Format : this could be more simplified >
timestamp,sequence,numericcode,threadID,modulename,servername,messagestring


The problem was that guaranteeing a message would be logged without impacting the performance of the application being logged meant that using guaranteed 'flush to disk' was out of the question if the logging code was part of the application. You either let the file system cache buffer your output, in which case you risk losing output if your application crashes, or you wait around while the operating system flushes your output to the log file.
------------------------------------------------------------------



< Alternatives to guarantee messages to be logged >
1. flush to disk immediately.
 - slow, overhead on a disk (writing repeatedly on the same sector)
 - logging guaranteed until a termination(or crash) of an application
2. run a separate logging program(service) and forward messages to it. 
 - It could be an OS' facility. : debugging data might be massive. should be avoided.
 - slow (using IPC)
 - logging guaranteed until a termination(or crash) of an application
 - independent on a crash of the application
 - central management of logs
3. don't flush, sacrificing a guarantee of logging until a termination(or crash) of an application(s)
 - fast
 - unflushed messages might be lost if a system or an application crashes.



< Design Choices >
1. Flushing to a disk immediately or not

2. Running a separate logging service
2-1. If 2 is yes, then will we use OS' logging service?

3. Fixed message format or Flexible
3-1. If fixed, what format?
(The implementation of flexible formatting should be more compicated and less robust)

4. Limiting the size of a log file (rolling?)
4-1. Aging of log files (create new files when necessary)
(Aging of log files cannot be implemented by inheritance of ostream)

5. Using Logger name(or id) (multiple loggers)
5-1. Using Hierarchical Logger namespace or not 
(exactly like LOG4J. because of inheritance, implementation will be complicated)

6. Using Process-wise singleton (or thread)
- Process-wise singleton : synchronization(whole logger) needed for thread-safety
- Thread-wise singleton : the thread-wise singleton would not need synchronization(whole logger) for thread-safety.
   settings should be copied across threads for the same logic.
   synchronization for accessing setting data&collection of loggers should be done.
   waiting time is minimized.
   per-thread logger collection is needed.
   implementation is more complicated; it might be less robust.

7. For OS-independent timestamps, what function(s) should be used?
time() & string conversion  ?

8. For run-time setting by loading an XML file, what XML parser should be used?
a candidate : Apache Xerces-C++ ?   (compatible with unix, win, cygwin)
http://xml.apache.org/xerces-c/

9. using ostream, or other possibilities?


Hee-Su
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20050406/b601b58b/attachment-0002.html>