[jira] [Comment Edited] (LOG4NET-587) Mutex ~ Access to the path is denied in log4net.Appender.RollingFileAppender.ActivateOptions()

["Dominik Psenner (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4NET-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326948#comment-16326948 ] 

Dominik Psenner edited comment on LOG4NET-587 at 1/16/18 9:57 AM:
------------------------------------------------------------------

Log4net is an open source logging framework entirely written by volunteers that formed into a community. You can take the source and modify it at will. This is part of the license agreement that you should have read. It is very unlikely that someone else can troubleshoot this specific issue better than you can because you know the environment where this happens best. It would be great if you contributed your findings and improvements back to the community.

 

The issue you are seeing was probably introduced with fixing another issue where rolling of files did unexpected things because multiple processes tried to roll the same files. Back then I introduced a mutex to synchronize the rolling across processes. I see two possible causes to the issue:

 
 # The environment that your application runs in does not grant required privileges to create the mutex.
 # The mutex creation code is buggy, meaning that it does not work at all in your environment or that it has race conditions or even worse.

I dont know how to reproduce the issue and therefore I, in the name of the community, ask you to find out what causes the issue so that we can improve the logging framework for your usecase.


was (Author: nachbarslumpi):
Log4net is an open source logging framework entirely written by volunteers that formed into a community. You can take the source and modify it at will. This is part of the license agreement that you should have read. It is very unlikely that someone else can troubleshoot this specific issue better than you can because you know the environment where this happens best. It would be great if you contributed your findings and improvements back to the community.

 

The issue you are seeing was probably introduced with fixing another issue where rolling of files did unexpected things because multiple processes tried to roll the same files. Back then I introduced a mutex to synchronize the rolling across processes. I see two possible causes to the issue:

 
 # The environment that your application runs in does not grant requires privileges to create the mutex.
 # The mutex creation code is buggy, meaning that it does not work at all or that it has race conditions or even worse.

I dont know how to reproduce the issue and therefore I, in the name of the community, ask you to find out what causes the issue so that we can improve the logging framework for your usecase.

> 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)