[
https://issues.apache.org/jira/browse/LOG4NET-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326778#comment-16326778
]
Kira Resari commented on LOG4NET-587:
-------------------------------------
Very funny. The mutex call happens inside a log4net class. I don't have access
to it. That is why I'm posting it as a bug on the log4net issue tracker.
> Mutex ~ Access to the path is denied in
> log4net.Appender.RollingFileAppender.ActivateOptions()
> ----------------------------------------------------------------------------------------------
>
> Key: LOG4NET-587
> URL: https://issues.apache.org/jira/browse/LOG4NET-587
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.0.8
> Environment: Windows Server 2012 R2
> Reporter: Kira Resari
> Priority: Major
>
> I have recently updated my log4net version from a really old Version (1.2.13)
> to the newest version, but ever since then, a component of my apache website
> service throws the following error message:
> {code:java}
> 2018-01-15 06:19:35,933 DEBUG - Exception-Message: Access to the path
> 'C__Rafina_LeBu_logs_NFDDL2.log' is denied.
> 2018-01-15 06:19:35,933 DEBUG - Exception-StackTrace: at
> System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
> at System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object
> userData)
> at
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
> at System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
> at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
> at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
> at log4net.Appender.RollingFileAppender.ActivateOptions()
> at NFCIn.Logging.InL4NLogFac.LogImp..ctor(String name)
> at NFCIn.Logging.InL4NLogFac.CrLog(ILoggerRepository repository,
> String name)
> at log4net.Repository.Hierarchy.Hierarchy.GetLogger(String name,
> ILoggerFactory factory)
> at log4net.Repository.Hierarchy.Hierarchy.GetLogger(String name)
> at log4net.Core.LoggerManager.GetLogger(Assembly repositoryAssembly,
> String name)
> at log4net.LogManager.GetLogger(String name)
> at NFCIn.Log.L4NFac.b(LogName id)
> at NFDDL.DDo.probeDL2(DateTime dateStart, DateTime dateEnd, String
> headStatus, String transmissionStatus, String supplier, String documenttype,
> String documentsubtype, Int32 processed, String clientId, String documentUser)
> at NFIISWServ.Serv.pr(String base64request){code}
> Since the crux of the problem seems to be happening inside a log4net function
> call, I figured I'd post this here. Or is there already a workaround for this?
> By the way, this is the rollingAppender we're using:
>
> {code:java}
> var rollingAppender = new RollingFileAppender
> {
> File = logFileName,
> AppendToFile = true,
> Encoding = Encoding.UTF8,
> RollingStyle = RollingFileAppender.RollingMode.Size,
> MaxSizeRollBackups = 0,
> MaxFileSize = logSettings.MaxFileSize,
> StaticLogFileName = true,
> LockingModel = new FileAppender.MinimalLock(),
> Layout =
> new PatternLayout(
> logSettings.Pattern),
> Threshold =
> this.NfLogLevelToInternalLogLevel(logSettings.LogLevel)
> };
> rollingAppender.ActivateOptions();{code}
>
> I have already tried changing the value of LockingModel to InterProcessLock
> or commenting out that line. However, both approaches have only escalated
> the problem.
> On the other hand, that way I was able to confirm that this particular
> problem only happens on one specific page of our web portal, and that the
> log4net logger works just fine in other sections. Here is a comparison of the
> last diverging call between a working and a not working path:
> Working:
> {code:java}
> Dim log As ILogger =
> loggingFactory.build(LogName.NFDDL).open("Document.Parse"){code}
> Not working:
> {code:java}
> Dim log As ILogger =
> loggingFactory.build(LogName.NFDDL).open("DocumentDao.probeDocumentList2"){code}
> The value inside (open) is merely a log entry that should be written into the
> log, so I don't think that could be it.
> —
> UPDATE:
> By now, I've managed to escalate the error. It no happens on all sorts of
> pages of the portal even with previously working function calls, even though
> after all my experimentation on the issue I rolled all my changes back to the
> version I had this morning using git where the now additionally affected
> pages were still working. My assumption is that somewhere during my
> experimentation log4net mutex-locked some files and never released that lock.
> Can someone please help me with this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
