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

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

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