[
https://issues.apache.org/jira/browse/LOG4J2-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17341378#comment-17341378
]
Ralph Goers commented on LOG4J2-3090:
-------------------------------------
GzCompressAction is using try-with-resources so the OutputStream should be
closed by Java when writing is complete. The action does not delete the source
file until after the try block completes. As far as Log4j goes, that is all we
can do. If there is a bug it would be in the JVM but it is possible that even
that is being buffered by the OS somehow.
> Why the log file was deleted when the compressd file has not been flushed to
> the disk?
> --------------------------------------------------------------------------------------
>
> Key: LOG4J2-3090
> URL: https://issues.apache.org/jira/browse/LOG4J2-3090
> Project: Log4j 2
> Issue Type: Question
> Affects Versions: 2.13.3
> Reporter: jasonyu
> Priority: Minor
>
> Here is the situation :
> 1、The appender is RollingFileAppender with SizeBasedTriaggeringPolicy, the
> rolling file pattern is extended to ".gz".
> 2、While the log4j2 executing rolling(compress) event, the linux server is
> rebooted by coincidence.
> As a result, the log file before rolling was deleted and the size of the
> compressed file was zero, which means the log message was lost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
