[
https://issues.apache.org/jira/browse/LOG4J2-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15303770#comment-15303770
]
Bernhard Mähr edited comment on LOG4J2-904 at 5/27/16 8:50 AM:
---------------------------------------------------------------
Here the capturing of the Logging during rollover:
{code}
2016-05-27 00:00:00,311 scheduler_Worker-5 TRACE PatternProcessor.getNextTime
returning 2016/05/28-00:00:00.000, nextFileTime=2016/05/27-00:00:00.000,
prevFileTime=2016/05/26-00:00:00.000, current=2016/05/27-00:00:00.310,
freq=DAILY
2016-05-27 00:00:00,318 scheduler_Worker-5 TRACE
DefaultRolloverStrategy.purge() took 0.0 milliseconds
2016-05-27 00:00:00,318 scheduler_Worker-5 DEBUG RollingFileManager executing
synchronous
FileRenameAction[C:\Oracle\Middleware\user_projects\domains\entw_domain\servers\entw_server\logs\app.log
to
C:\Oracle\Middleware\user_projects\domains\entw_domain\servers\entw_server\logs\app-2016-05-26-4.log,
renameEmptyFiles=false]
{code}
Looking at the code of FileRenameAction I would assume one of these
possibilities:
- the source.renameTo(destination) is successful and for some reason the old
content of the file is written to the new file
- the source.renameTo(destination) fails, the copyFile(source, destination) is
successful but the source.delete() fails silently
The logging doesn't show which possibility is executed.
was (Author: bmaehr):
Here the capturing of the Logging during rollover:
{code}
2016-05-27 00:00:00,311 scheduler_Worker-5 TRACE PatternProcessor.getNextTime
returning 2016/05/28-00:00:00.000, nextFileTime=2016/05/27-00:00:00.000,
prevFileTime=2016/05/26-00:00:00.000, current=2016/05/27-00:00:00.310,
freq=DAILY
2016-05-27 00:00:00,318 scheduler_Worker-5 TRACE
DefaultRolloverStrategy.purge() took 0.0 milliseconds
2016-05-27 00:00:00,318 scheduler_Worker-5 DEBUG RollingFileManager executing
synchronous
FileRenameAction[C:\Oracle\Middleware\user_projects\domains\entw_domain\servers\entw_server\logs\app.log
to
C:\Oracle\Middleware\user_projects\domains\entw_domain\servers\entw_server\logs\app-2016-05-26-4.log,
renameEmptyFiles=false]
{code}
Looking at the code of FileRenameAction I would assume one of these
possibilities:
- the source.renameTo(destination) is successful and for some reason the old
content of the file is written to the new file
- the source.renameTo(destination) fails, the copyFile(source, destination) is
successful but the source.delete() fails silently
The logging doesn't show which possibility is executed.
> RollingFile appender doesn't zip and create new files
> -----------------------------------------------------
>
> Key: LOG4J2-904
> URL: https://issues.apache.org/jira/browse/LOG4J2-904
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.1
> Environment: Windows 7
> Reporter: Stephen A. Weinfield
>
> Using TimeBasedTriggeringPolicy, with a filePattern of
> {{f:/Log4J/$$\{date:yyyy-MM}/IIB-%d\{MM-dd-yyyy}-%i.log.zip}} and a fileName
> of f:/Log4J/IIB.log:
> on date change, directory is created but filename is not zipped. Also old
> file is not cleared out, but just appended to.
> Log4j2.xml:
> {code}
> <Configuration status = "warn" name = "Log4j2_Configuration" monitorInterval
> = "60" packages = "">
> <Appenders>
> <RollingFile name = "RollingFile" fileName = "f:/Log4J/IIB.log"
> filePattern = "f:/Log4J/$${date:yyyy-MM}/IIB-%d{MM-dd-yyyy}-%i.log.zip" >
> <PatternLayout>
> <Pattern>%d %p %c{1} %m%n%n</Pattern>
> </PatternLayout>
> <Policies>
> <TimeBasedTriggeringPolicy interval = "1" modulate = "true"/>
> </Policies>
> <DefaultRolloverStrategy fileIndex = "min" max = "7"
> compressionLevel = "5"/>
> </RollingFile>
> </Appenders>
> <Loggers>
> <Root level = "trace">
> <AppenderRef ref = "RollingFile" level = "warn"/>
> </Root>
> </Loggers>
> </Configuration>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
