--- Meera Rajaram <[EMAIL PROTECTED]> wrote: > I am using version 1.2.9 of log4Net. I tried working with this and > found > that with Minimal Locking the FileShare mode is FileShare.Read. So > any > other process which even tries to open the file for writing will get > an > exception. But if the FileShare mode is made as ReadWrite, it seems > to > work fine for multiple processes.
You want other processes to be able to open the log file and write to it while log4net is actively writing to the file? Don't you think that's a bad idea? > I also found that if RollingFileAppender is made to rollover based on > Size of file where maxRollovers > 1 - then when multiple processes > are > writing to the same file it causes a problem. Because the typical > naming > convention of the file on rollovers is logFile.log, logFile.log.1, > logFile.log.2 and so on. > > If currently the first process P1 rolled over the file based on size > to > LogFile.log.1, it internally knows that the next name should be > 'logFile.log.2'. Process P2 on the other hand does not know that the > next name during rollover should be 'logFile.log.2'. For P2, the next > file name would still be 'logFile.log.1'. So if it ever happens that > when P2 is writing to logFile.log and the size exceeds, then P2 would > simply rename the file to logFile.log.1 (overwriting the previous > file > that was created). > > Is there some setting that needs to be specified that can overcome > this > issue? Not that I'm aware of. This sounds like a limitation of the FileAppender. Have you tested this or is this just a general question? FileAppender may be smart enough to check the size of the file before it attempts to write. I'm of the opinion that you shouldn't use the MinimalLock locking model unless you don't have any other options. Are you able to have all processes log to a more multi-process friendly target like a database then use SQL to extract the logs from specific processes when you need the data?
