<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=ks_c_5601-1987">
<META content="MSHTML 6.00.2900.2604" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi, </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I hope this could be useful for discussing
logging.</FONT></DIV>
<DIV><FONT face=Arial size=2><BR>----------------- from IGSTK requirements and
blake_IGSTKMeeting212 ---------------<BR>5.7 Logging Requirements</DIV>
<DIV> </DIV>
<DIV>5.7.1 The IGSTK platform shall contain a general, <BR>centralized
logging capability <BR>that can be used for all IGSTK components.</DIV>
<DIV> </DIV>
<DIV>5.7.2 The logging capability shall support timestamps<BR> for the
audited information.<BR></DIV>
<DIV>5.7.3 The logging capability shall enable logging <BR>for multiple
components concurrently and support auditing into multiple files.</DIV>
<DIV> </DIV>
<DIV>* Should have run-time and compile-time switches <BR>to adjust logging and
validation
sensitivity<BR>-----------------------------------------------------------------</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>< More Requirements or Design Candidates ><BR>------ from <A
href="http://www.codeproject.com/cpp/loggerservice.asp">http://www.codeproject.com/cpp/loggerservice.asp</A>
-----<BR># Survive a crash of the application(s) being logged.<BR># 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.<BR># Log, on a per
module basis, things that each developer thought was relevant.<BR># Support Log
Levels<BR># Be able to 'age' a logfile.<BR># Be an easy retrofit to existing
code.<BR># Limit the size of a log file.</DIV>
<DIV> </DIV>
<DIV>< A Candidate Format : this could be more simplified
><BR>timestamp,sequence,numericcode,threadID,modulename,servername,messagestring</DIV>
<DIV> </DIV>
<DIV><BR>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.<BR>------------------------------------------------------------------</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>< Alternatives to guarantee messages to be logged ><BR>1. flush to
disk immediately.<BR> - slow, overhead on a disk (writing repeatedly on the
same sector)<BR> - logging guaranteed until a termination(or crash) of an
application<BR>2. run a separate logging program(service) and forward messages
to it. <BR> - It could be an OS' facility. : debugging data might be
massive. should be avoided.<BR> - slow (using IPC)<BR> - logging
guaranteed until a termination(or crash) of an application<BR> -
independent on a crash of the application<BR> - central management of
logs<BR>3. don't flush, sacrificing a guarantee of logging until a
termination(or crash) of an application(s)<BR> - fast<BR> - unflushed
messages might be lost if a system or an application crashes.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>< Design Choices ><BR>1. Flushing to a disk immediately or not</DIV>
<DIV> </DIV>
<DIV>2. Running a separate logging service<BR>2-1. If 2 is yes, then will we use
OS' logging service?</DIV>
<DIV> </DIV>
<DIV>3. Fixed message format or Flexible<BR>3-1. If fixed, what format?<BR>(The
implementation of flexible formatting should be more compicated and less
robust)</DIV>
<DIV> </DIV>
<DIV>4. Limiting the size of a log file (rolling?)<BR>4-1. Aging of log files
(create new files when necessary)<BR>(Aging of log files cannot be implemented
by inheritance of ostream)</DIV>
<DIV> </DIV>
<DIV>5. Using Logger name(or id) (multiple loggers)<BR>5-1. Using Hierarchical
Logger namespace or not <BR>(exactly like LOG4J. because of inheritance,
implementation will be complicated)</DIV>
<DIV> </DIV>
<DIV>6. Using Process-wise singleton (or thread)<BR>- Process-wise singleton :
synchronization(whole logger) needed for thread-safety<BR>- Thread-wise
singleton : the thread-wise singleton would not need synchronization(whole
logger) for thread-safety.<BR> settings should be copied across
threads for the same logic.<BR> synchronization for accessing
setting data&collection of loggers should be
done.<BR> waiting time is
minimized.<BR> per-thread logger collection is
needed.<BR> implementation is more complicated; it might be
less robust.</DIV>
<DIV> </DIV>
<DIV>7. For OS-independent timestamps, what function(s) should be
used?<BR>time() & string conversion ?</DIV>
<DIV> </DIV>
<DIV>8. For run-time setting by loading an XML file, what XML parser should be
used?<BR>a candidate : Apache Xerces-C++ ? (compatible with unix,
win, cygwin)<BR><A
href="http://xml.apache.org/xerces-c/">http://xml.apache.org/xerces-c/</A></DIV>
<DIV> </DIV>
<DIV>9. using ostream, or other possibilities?</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>
<DIV><FONT face=Arial size=2>Hee-Su</FONT></DIV>
<DIV> </DIV></FONT></DIV></BODY></HTML>