You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by ni...@apache.org on 2005/04/03 20:02:18 UTC

cvs commit: logging-log4net/src/Appender RemotingAppender.cs

nicko       2005/04/03 11:02:18

  Modified:    src/Appender RemotingAppender.cs
  Log:
  Updated doc comments
  
  Revision  Changes    Path
  1.9       +4 -6      logging-log4net/src/Appender/RemotingAppender.cs
  
  Index: RemotingAppender.cs
  ===================================================================
  RCS file: /home/cvs/logging-log4net/src/Appender/RemotingAppender.cs,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- RemotingAppender.cs	17 Jan 2005 20:18:41 -0000	1.8
  +++ RemotingAppender.cs	3 Apr 2005 18:02:18 -0000	1.9
  @@ -51,12 +51,11 @@
   	/// number of non obvious reasons. The remoting infrastructure will 
   	/// flow thread local variables (stored in the <see cref="CallContext"/>),
   	/// if they are marked as <see cref="ILogicalThreadAffinative"/>, across the 
  -	/// remoting boundary. This means that a large amount of unnecessary data could
  -	/// be flowed across the remoting boundary. If the server is not contactable then
  +	/// remoting boundary. If the server is not contactable then
   	/// the remoting infrastructure will clear the <see cref="ILogicalThreadAffinative"/>
   	/// objects from the <see cref="CallContext"/>. To prevent a logging failure from
   	/// having side effects on the calling application the remoting call must be made
  -	/// from a separate thread to the use used by the application. A <see cref="ThreadPool"/>
  +	/// from a separate thread to the one used by the application. A <see cref="ThreadPool"/>
   	/// thread is used for this. If no <see cref="ThreadPool"/> thread is available then
   	/// the events will block in the thread pool manager until a thread is available.</para>
   	/// <para>
  @@ -161,12 +160,11 @@
   		/// This is very important for a number of non obvious reasons. The remoting
   		/// infrastructure will flow thread local variables (stored in the <see cref="CallContext"/>),
   		/// if they are marked as <see cref="ILogicalThreadAffinative"/>, across the 
  -		/// remoting boundary. This means that a large amount of unnecessary data could
  -		/// be flowed across the remoting boundary. If the server is not contactable then
  +		/// remoting boundary. If the server is not contactable then
   		/// the remoting infrastructure will clear the <see cref="ILogicalThreadAffinative"/>
   		/// objects from the <see cref="CallContext"/>. To prevent a logging failure from
   		/// having side effects on the calling application the remoting call must be made
  -		/// from a separate thread to the use used by the application. A <see cref="ThreadPool"/>
  +		/// from a separate thread to the one used by the application. A <see cref="ThreadPool"/>
   		/// thread is used for this. If no <see cref="ThreadPool"/> thread is available then
   		/// the events will block in the thread pool manager until a thread is available.
   		/// </remarks>