[
https://issues.apache.org/jira/browse/LOG4NET-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927616#comment-15927616
]
Dominik Psenner commented on LOG4NET-552:
-----------------------------------------
I'm unsure whether we can just remove the overwriting of files. Have you tried
to do your modifications and ran the tests? If I had the time to rewrite the
rolling file appender, I would not implement mechanisms that overwrite files
but rather find a better filename for the rolling destination. For instance
consider this situation:
There are the following logfiles:
* Some.log [size=3MB]
* Some.2017-03-16.log [size=45MB]
and the time is 2017-03-16 08:30 and therefore the rolling logic would like to
roll over "Some.log" again. Then I would expect this outcome:
* Some.log [size=0MB]
* Some.2017-03-16.log [size=45MB]
* Some.2017-03-16.1.log [size=3MB]
This behavior however totally breaks the mechanisms that try to limit the
number of rolled files. Unfortunately modifications to the rolling file
appender can have many side effects that break existing usecases and therefore
we avoid patching it. As for your usecase, I again advise you to rethink your
logging configuration. You should avoid having several processes that write
into the same logfiles! If you want a combined log event for all the processes
you have, use a remote appender / adonet appender /...
> Incorrect behavior of RollingFileAppender while rolling files, if multiple
> processes appending into same file
> -------------------------------------------------------------------------------------------------------------
>
> Key: LOG4NET-552
> URL: https://issues.apache.org/jira/browse/LOG4NET-552
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 1.2.15
> Environment: Windows Server 2008 R2 Enterprise
> Reporter: Sachin Abaso Patil
> Priority: Blocker
>
> Hi Team,
> This issue has become blocker for us, as on our production environment,
> multiple processes are appending log into single log file which has no issue,
> but while rolling it overwrites files and thus missing log entries.
> Based on link below, it looks like log file rolling mechanism of log4net is
> not process safe even after using FileAppender.InterProcessLock.
> Link: https://issues.apache.org/jira/browse/LOG4NET-485
> Also, in FAQ (https://logging.apache.org/log4net/release/faq.html) under
> section “How do I get multiple process to log to the same file?”, it has been
> clearly mentioned that, rolling files is simply not compatible with multiple
> process scenario.
> My questions,
> 1. We are using version “1.2.15”. Are you planning to fix above mentioned
> rolling issue in upcoming release? If yes then please provide tentative
> release date.
> 2. We had incorporated log4net in our project in year 2009, had FAQ
> mentioned this limitation (rolling file not compatible with multi process) in
> year 2009? Because we while studying log4net during year 2009 we do not
> remember seeing this note in FAQ?
> Requesting you to please respond as soon as possible with your comments.
> Below is how we have configured appender for all processes,
> <appender name="RollingFileAppender"
> type="log4net.Appender.RollingFileAppender">
> <threshold value ="ERROR"/>
> <file value="${SystemDrive}\LogFiles\Example.log" />
> <param name="LockingModel"
> type="log4net.Appender.FileAppender+MinimalLock" />
> <appendToFile value="true" />
> <maximumFileSize value="100MB" />
> <staticLogFileName value="true"/>
> <maxSizeRollBackups value="-1" />
> <countDirection value="1" />
> <datePattern value=".yyyyMMddHH'.log'"/>
> <rollingStyle value="Composite" />
> <ignoreExceptionItemAgeLimit value="false" />
> <exceptionItemAgeLimit value="00:00:59" />
> <layout type="log4net.Layout.PatternLayout">
> <param name="conversionPattern" value ="%utcdate{yyyy-MM-dd
> HH:mm:ss.fff}|%-5level|%property{EventID}|%property{log4net:HostName}|%appdomain|%property{ProcessID}|%thread|%message%newline"/>
> </layout>
> </appender>
> Thanks,
> Sachin Patil
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
