[jira] [Created] (LOG4NET-634) Attempting to flush a FileAppender throws LockStateException

["Davyd McColl (JIRA)" <ji...@apache.org>]

Davyd McColl created LOG4NET-634:
------------------------------------

             Summary: 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
         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
(v7.6.3#76005)