[ https://issues.apache.org/jira/browse/LOG4NET-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davyd McColl reassigned LOG4NET-634: ------------------------------------ Assignee: Davyd McColl > Attempting to flush a FileAppender throws LockStateException > ------------------------------------------------------------ > > Key: LOG4NET-634 > URL: https://issues.apache.org/jira/browse/LOG4NET-634 > Project: Log4net > Issue Type: Bug > Components: Appenders > Affects Versions: 2.0.8 > Reporter: Davyd McColl > Assignee: Davyd McColl > Priority: Major > Labels: bug, inconsistency > Attachments: TestProject1.zip > > > I'd like to be able to have file appenders which do not immediately flush, > but instead flush on command. > > The documentation for log4net, as well as the api interface appears to > communicate that this is possible. > > However, when I actually _try_ to do this (after configuring ImmediateFlush > to false), I get the following exception: > log4net.Appender.FileAppender+LockingStream+LockStateException: The file is > not currently locked > > Which is surprising, because, yes, of course the file isn't locked – nothing > is writing to it. > > Whilst spelunking the code to figure out what I could possibly be doing > wrong, I also stumbled across some logic which I find confusing, and would > love to have cleared up: > > # XmlConfigurator, on .net standard, cannot configure for all repositories – > it must accept a repository, where .net framework variants do not need this. > Why? How do I configure my entire application from .net core then? > # the Flush method on a FileAppender takes a timeout value – which is never > used. Why? > # the Flush method on LogManager behaves very differently from netstandard > than from net framework – the latter attempts to flush for the repository > associated with the calling assembly where the former simply returns false. > Why? > > All-in-all, I thought that I had a simple requirement to be able to flush a > logfile to disk, but it turns out to have been an adventure in confusion on > my part. > -- This message was sent by Atlassian Jira (v8.3.4#803005)