[
https://issues.apache.org/jira/browse/LOG4NET-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761099#action_12761099
]
John Fairhall commented on LOG4NET-231:
---------------------------------------
Have tracked the issue. We have one java application running as a service that
starts up our c# application. The missing backup logs were generating output on
stderr, which the java app was not configured to read. As nothing was reading
it's stderr, the c# app blocked.
I'd say this issue is resolved, with a further comment that it should have been
straightforward to stifle the stderr output from the logger, but isn't.
> App hangs on log attempt when non-contiguous rolling log files exist
> --------------------------------------------------------------------
>
> Key: LOG4NET-231
> URL: https://issues.apache.org/jira/browse/LOG4NET-231
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 1.2.10
> Environment: Win32, Win Server 2003, C# app
> Reporter: John Fairhall
> Fix For: 1.2.11
>
>
> Application has this log4net config:
> <log4net>
> <appender name="RollingFile" type="log4net.Appender.RollingFileAppender">
> <file value="..\log\OOPCollector.log" />
> <appendToFile value="false" />
> <maximumFileSize value="5MB" />
> <maxSizeRollBackups value="5" />
> <lockingModel type="log4net.Appender.FileAppender+MinimalLock"
> />
> <layout type="log4net.Layout.PatternLayout">
> <conversionPattern value="%date %5level [%thread] %logger -
> %message%newline" />
> </layout>
> </appender>
> <root>
> <level value="INFO" />
> <appender-ref ref="RollingFile" />
> </root>
> </log4net>
> We are attemping to keep current + 5 backup logs.
> Somehow, the resulting logs for the OOPCollector app became;
> OOPCollector.log
> OOPCollector.log.5
> Starting the app with only those logs already existing causes the app to stop
> on a log attempt permanently.
> The OOPCollector.log.5 log dissappears but the OOPCollector.log does not get
> renamed to OOPCollector.log.1, and no new OOPCollector.log is created.
> The issue also occurs if the directory contains
> OOPCollector.log
> OOPCollector.log.4
> except that .4 does get renamed to .5, but otherwise same problem.
> Directory containining
> OOPCollector.log
> OOPCollector.log.3
> works as expected.
> Have set config to store 10 backups, and have same issue with
> OOPCollector.log and OOPCollector.log.10, and OOPCollector.log and
> OOPCollector.log.9.
> So looks like a fencepost error with rollover.
> We are also getting OOPCollector.<timestamp>.1, .2, .3 files in the directory
> occaisionally for no apparent reason.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
