[
https://issues.apache.org/jira/browse/LOG4NET-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131922#comment-16131922
]
ASF GitHub Bot commented on LOG4NET-552:
----------------------------------------
GitHub user ssachin3108 opened a pull request:
https://github.com/apache/logging-log4net/pull/15
https://issues.apache.org/jira/browse/LOG4NET-552
services installed on production box are separate process and are
configured to write log into single log file. Due to this following two issues
are happening,
During write/append operation some processes are failing with error “Unable
to acquire lock on file. The process cannot access the file because it is being
used by another process”. This is because one process acquires lock (thread
safe not process safe) for writing into log file and simultaneously another is
trying to acquire lock and fails with above error and it just skips writing
into log file.
During rolling operation, rolled file gets created with less than 1KB size.
Thus log entries are lost. Upon investigation we found that, rolling operation
is protected by system wide Mutex lock. At the time of rolling, multiple
processes may come at the same time for rolling and first process will roll the
original file correctly and give a different name to rolled file and re-create
blank original file. Now the second process which would have come for rolling
will roll the blank original file and overwrite the rolled file created by
first process and thus rolled file is losing the data.
We locally have fixed above issues by changing latest log4net source code.
We have kept locking model as “MinimalLock” which is current configuration in
production. During append operation for acquirelock/releaselock we added system
wide mutex so that each process will wait for other process to complete append
operation. Thus it will not skip log from being written.
During rolling operation we added check whether rolling is already happened
by some other process. If yes then skip rolling operation. This will resolve
rolling file overwrite by other process issue.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ssachin3108/logging-log4net-1 develop
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/logging-log4net/pull/15.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #15
----
commit bd375a491e8477908b9085d71b6e309340a0e18d
Author: spatil <[email protected]>
Date: 2017-08-18T08:46:30Z
https://issues.apache.org/jira/browse/LOG4NET-552
services installed on production box are separate process and are
configured to write log into single log file. Due to this following two issues
are happening,
During write/append operation some processes are failing with error “Unable
to acquire lock on file. The process cannot access the file because it is being
used by another process”. This is because one process acquires lock (thread
safe not process safe) for writing into log file and simultaneously another is
trying to acquire lock and fails with above error and it just skips writing
into log file.
During rolling operation, rolled file gets created with less than 1KB size.
Thus log entries are lost. Upon investigation we found that, rolling operation
is protected by system wide Mutex lock. At the time of rolling, multiple
processes may come at the same time for rolling and first process will roll the
original file correctly and give a different name to rolled file and re-create
blank original file. Now the second process which would have come for rolling
will roll the blank original file and overwrite the rolled file created by
first process and thus rolled file is losing the data.
We locally have fixed above issues by changing latest log4net source code.
We have kept locking model as “MinimalLock” which is current configuration in
production. During append operation for acquirelock/releaselock we added system
wide mutex so that each process will wait for other process to complete append
operation. Thus it will not skip log from being written.
During rolling operation we added check whether rolling is already happened
by some other process. If yes then skip rolling operation. This will resolve
rolling file overwrite by other process issue.
----
> 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.4.14#64029)
