[
https://issues.apache.org/jira/browse/LOG4NET-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15946591#comment-15946591
]
Sachin Abaso Patil commented on LOG4NET-552:
--------------------------------------------
Hi Dominik,
1. We understand that our fix is going to change current behaviour of minimal
locking model and going to hamper users who are using minimal lock but don't
want to use Mutex. But its the requirement of our customer that we can not
change logging configuration. But to control whether to enable mutex locking in
minimal lock or not, we can think of introducing configurable flag for it. This
flag user will enable if he needs mutex level locking to protect append
operation across processes for minimal locking model. By default mutex level
locking will be disabled.
2. We have tested this fix and going to use it in production. So, we wanted to
know your review of this fix whether you will see any side effects.
3. This fix is currently protecting date based rolling across process and not
size based. Because in our production, date/time based rolling happens first
and there is currently no chance for size based rolling. To protect size based
rolling across processes. we have thought of solution. Currently we can not put
efforts on this but can provide approach to you.
Please let us know your comments.
Thanks,
Sachin Patil
> 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
> Attachments: Modification in AdjustFileBeforeAppend.png
>
>
> 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)
