logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ni...@apache.org
Subject cvs commit: logging-log4net/xdocs/src/release faq.xml
Date Mon, 02 May 2005 21:30:22 GMT
nicko       2005/05/02 14:30:22

  Modified:    xdocs/src/release faq.xml
  Log:
  Updated FAQ to include information on FileAppender MinimalLock model
  
  Revision  Changes    Path
  1.5       +20 -12    logging-log4net/xdocs/src/release/faq.xml
  
  Index: faq.xml
  ===================================================================
  RCS file: /home/cvs/logging-log4net/xdocs/src/release/faq.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- faq.xml	2 May 2005 21:12:42 -0000	1.4
  +++ faq.xml	2 May 2005 21:30:22 -0000	1.5
  @@ -620,29 +620,37 @@
   
   				<section id="single-file" name="How do I get multiple process to log to the same
file?">
   					<p>
  -						The <span class="code">FileAppender</span> holds a write lock on the
log
  -						file while it is logging. This prevents other processes from writing to the
  -						file, therefore it is not possible to have multiple processes log directly 
  -						to the same log file, even if they are on the same machine.
  -					</p>
  -					<p>
  -						You may have each process log to a <span class="code">RemotingAppender</span>.

  -						The receiving <span class="code">RemoteLoggingServerPlugin</span> (or

  -						<span class="code">IRemoteLoggingSink</span>) can receive all the events
and 
  -						send them to a single log file.
  +						By default the <span class="code">FileAppender</span> holds an exclusive
write 
  +						lock on the log file while it is logging. This prevents other processes from 
  +						writing to the file. The <span class="code">FileAppender</span> can be
configured
  +						to use a different locking model, <span class="code">MinimalLock</span>,
that
  +						only acquires the write lock while a log is being written. This allows multiple
  +						processes to interleave writes to the same file, albeit with a loss in performance.
  +						See the <a href="config-examples.html#fileappender">FileAppender config examples</a>
  +						for an example <span class="code">MinimalLock</span> configuration.
  +					</p>
  +					<p>
  +						While the <span class="code">MinimalLock</span> model may be used to
interleave
  +						writes to a single file it may not be the optimal solution, especially when
  +						logging from multiple machines. Alternatively you may have one or more processes
  +						log to <span class="code">RemotingAppenders</span>. 
  +						Using the <span class="code">RemoteLoggingServerPlugin</span> (or 
  +						<span class="code">IRemoteLoggingSink</span>) a process can receive all
the events and 
  +						log them to a single log file.
   					</p>
   				</section>
   				<p><a href="#top">Back to Top</a></p>
   				
   
  -				<section id="distributed" name="If I have many processes across multiple hosts (possibly
across multiple time zones) logging to the same file using the method above, what happens
to timestamps?">
  +				<section id="distributed" name="If I have many processes across multiple hosts (possibly
across multiple time zones) logging to the same file using the RemotingAppender, what happens
to timestamps?">
   					<p>
   						The timestamp is created when the logging event is created. That is so say, 
   						when the <span class="code">Debug</span>, <span class="code">Info</span>,

   						<span class="code">Warn</span>, <span class="code">Error</span>
   						or <span class="code">Fatal</span> method is invoked. This is unaffected
by the time at 
   						which they may arrive at a remote server. Since the timestamps are 
  -						stored in UTC format inside the event, they all appear in the same time zone as 
  +						transmitted in UTC format by the <span class="code">RemotingAppender</span>,

  +						they all appear in the same time zone as 
   						the host creating the logfile. Since the clocks of various machines may not be 
   						synchronized, this may account for time interval inconsistencies between events 
   						generated on different hosts.
  
  
  

Mime
View raw message