标签：eve really cas eal man mutex elf entry remoting
http://logging.apache.org/log4net/release/faq.html#single-file
Before you even start trying any of the alternatives provided, ask yourself whether you really need to have multiple processes log to the same file, then don‘t do it ;-).
FileAppender offers pluggable locking models for this usecase but all existing implementations have issues and drawbacks.
By default the FileAppender holds an exclusive write lock on the log file while it is logging. This prevents other processes from writing to the file. This model is known to break down with (at least on some versions of) Mono on Linux and log files may get corrupted as soon as another process tries to access the log file.
MinimalLock 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 considerable loss in performance.
InterProcessLock doesn‘t lock the file at all but synchronizes using a system wide Mutex. This will only work if all processes cooperate (and use the same locking model). The acquisition and release of a Mutex for every log entry to be written will result in a loss of performance, but the Mutex is preferable to the use of MinimalLock.
If you use RollingFileAppender things become even worse as several process may try to start rolling the log file concurrently. RollingFileAppender completely ignores the locking model when rolling files, rolling files is simply not compatible with this scenario.
A better alternative is to have your processes log to RemotingAppenders. Using the RemoteLoggingServerPlugin (or IRemoteLoggingSink) a process can receive all the events and log them to a single log file. One of the examples shows how to use the RemoteLoggingServerPlugin.
标签：eve really cas eal man mutex elf entry remoting
原文地址：https://www.cnblogs.com/chucklu/p/10207248.html
