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