GitHub user ssachin3108 opened a pull request:
https://github.com/apache/logging-log4net/pull/16
Implemented review comments given under Pull Request
Implemented review comments given under Pull Request
https://github.com/apache/logging-log4net/pull/15
Below was question asked in above PR,
Question: Are you aware of that a mutex lock when opening a file has a
significant performance impact when using minimal lock scenario?
ANS: Yes we are aware about this. But as our customer want to have multiple
processes writing into same file using RollingFileAppender, we choose to
implement mutex in minimal lock model. But we have make usage of this mutex
configurable.
Question: Would the patch also work without the mutex but only the fix in
the RollingFileAppender class?
Ans: Yes we have added new configuration
By Default mutex won't be applied with minimal lock unless above config key
is set to true.
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/16.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 #16
----
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.
commit c77a38322a12c42c695f1f97eadfbff1e30f219c
Author: spatil <[email protected]>
Date: 2017-08-19T10:14:31Z
Implemented review comments given under Pull Request
https://github.com/apache/logging-log4net/pull/15
Below was question asked in above PR,
Question: Would the patch also work without the mutex but only the fix in
the RollingFileAppender class?
Ans: Yes we have added new configuration <useMutexWithMinimalLock
value="false"/>
By Default mutex won't be applied with minimal lock unless above config key
is set to true.
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
