log4net RemotingAppender

RemotingAppender

For full details see the SDK Reference entry: log4net.Appender.RemotingAppender.

The following example shows how to configure the RemotingAppender to deliver logging events to a specified Sink (in this example the sink is tcp://localhost:8085/LoggingSink). In this example the events are delivered in blocks of 95 events because of the BufferSize. No events are discarded. The OnlyFixPartialEventData option allows the appender to ignore certain logging event properties that can be very slow to generate (e.g. the calling location information).

1. <appender name="RemotingAppender" type="log4net.Appender.RemotingAppender" >
2. <sink value="tcp://localhost:8085/LoggingSink" />
3. <lossy value="false" />
4. <bufferSize value="95" />
5. <onlyFixPartialEventData value="true" />
6. </appender>

This example configures the RemotingAppender to deliver the events only when an event with level ERROR or above is logged. When the events are delivered, up to 200 (BufferSize) previous events (regardless of level) will be delivered to provide context. Events not delivered will be discarded.

1. <appender name="RemotingAppender" type="log4net.Appender.RemotingAppender" >
2. <sink value="tcp://localhost:8085/LoggingSink" />
3. <lossy value="true" />
4. <bufferSize value="200" />
5. <onlyFixPartialEventData value="true" />
6. <evaluator type="log4net.Core.LevelEvaluator">
7. <threshold value="ERROR"/>
8. </evaluator>
9. </appender>

RemotingAppender Class

Remarks

---

 

This Appender is designed to deliver events to a remote sink. That is any object that implements the RemotingAppender. IRemoteLoggingSink interface. It delivers the events using .NET remoting. The object to deliver events to is specified by setting the appenders Sink property.

The RemotingAppender buffers events before sending them. This allows it to make more efficient use of the remoting infrastructure.

Once the buffer is full the events are still not sent immediately. They are scheduled to be sent using a pool thread. The effect is that the send occurs asynchronously. This is very important for a number of non obvious reasons. The remoting infrastructure will flow thread local variables (stored in the CallContext), if they are marked as ILogicalThreadAffinative, across the remoting boundary. If the server is not contactable then the remoting infrastructure will clear the ILogicalThreadAffinative objects from the 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 one used by the application. A ThreadPool thread is used for this. If no ThreadPool thread is available then the events will block in the thread pool manager until a thread is available.

Because the events are sent asynchronously using pool threads it is possible to close this appender before all the queued events have been sent. When closing the appender attempts to wait until all the queued events have been sent, but this will timeout after 30 seconds regardless.

If this appender is being closed because the ProcessExit event has fired it may not be possible to send all the queued events. During process exit the runtime limits the time that a ProcessExit event handler is allowed to run for. If the runtime terminates the threads before the queued events have been sent then they will be lost. To ensure that all events are sent the appender must be closed before the application exits. See Shutdown() for details on how to shutdown log4net programmatically.