【问题标题】:Logback file appender doesn't flush immediatelyLogback 文件附加程序不会立即刷新
【发布时间】:2012-08-03 12:30:10
【问题描述】:

在某些情况下,我需要立即强制刷新 logback 的文件附加程序。我在docs 中发现此选项默认启用。神秘的是,这不起作用。正如我在源代码中看到的那样,底层过程正确地涉及BufferedOutputSreamBufferedOutputSream.flush() 有什么问题吗?这可能与冲洗问题有关。

更新: 我在 Windows XP Pro SP 3 和 Red Hat Enterprise Linux Server 版本 5.3 (Tikanga) 上发现了这个问题。 我使用了这些库:

jcl-over-slf4j-1.6.6.jar
logback-classic-1.0.6.jar
logback-core-1.0.6.jar
slf4j-api-1.6.6.jar

logback.xml 是:

<configuration>
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>/somepath/file.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
            <fileNamePattern>file.log.%i</fileNamePattern>
            <minIndex>1</minIndex>
            <maxIndex>3</maxIndex>
        </rollingPolicy>
        <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <maxFileSize>5MB</maxFileSize>
        </triggeringPolicy>
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
        </encoder>
    </appender>

    <root level="debug">
        <appender-ref ref="FILE"/>
    </root>
</configuration>

更新: 我会提供一个单元测试,但这似乎并不那么简单。 让我更清楚地描述这个问题。

  1. 发生记录事件
  2. 事件被传递到文件追加器中
  3. 事件以定义的模式序列化
  4. 事件的序列化消息被传递到文件附加程序,并且是 即将写入输出流
  5. 写入流已完成,输出流已刷新(我已经 检查实施)。请注意,immidiateFlush 为真 默认so方法flush()被显式调用
  6. 文件中没有结果!

稍后,当一些底层缓冲区流动时,该事件出现在文件中。 那么问题来了:输出流能保证立即刷新吗?

说实话,我已经通过实现我自己的ImmediateRollingFileAppender 解决了这个问题,它利用了FileDescriptor 的即时同步功能。有兴趣的可以关注this

所以这不是 logback 问题。

【问题讨论】:

  • 您在哪个操作系统上发现了这个?
  • 发布你的 logback 配置。
  • 你能定义“神秘地这不起作用”吗?提供单元测试将非常有用。 BTW,你用的是哪个版本的JDK?

标签: java logging io logback flush


【解决方案1】:

许多监控中间件通过检查时间戳和文件大小的更新来发现新事件。为此,它需要记录事件的时间,更新时间戳和文件大小。

这门课可以解决

public class MyFileAppender<E> extends FileAppender<E> {
    protected void writeOut(E event) throws IOException {
        super.writeOut(event);
        ResilientFileOutputStream resilientFos = (ResilientFileOutputStream) super.getOutputStream();
        resilientFos.flush();
        resilientFos.getChannel().force(true);
    }
}

为 appender 设置 MyFileAppender 类。

<appender name="FILE" class="MyFileAppender">

我希望 logback 能解决这个问题。

【讨论】:

  • 我遇到了这个解决方案的问题,因为中断的线程“resilientFos.getChannel().force(true)”关闭了文件通道,此后记录停止。
【解决方案2】:

你做得很好——做得很好。这是一个更简洁的建议:

public class ImmediateFlushPatternLayoutEncoder extends PatternLayoutEncoder {
    public void doEncode(ILoggingEvent event) throws IOException {
        super.doEncode(event);
        if (isImmediateFlush()) {
             if (outputStream.os instanceof FileOutputStream) {
                 ((FileOutputStream) outputStream.os).getFD().sync();
             }
        }
    }
}

在配置中,您必须使用特定的编码器:

<encoder class="ch.qos.logback.core.recovery.ImmediateFlushPatternLayoutEncoder">

未测试。可能会有字段可见性问题,需要使用 logback ch.qos.logback.core.recovery 包本身

顺便说一句,我邀请您到 submit a bug report 登录以在 LayoutWrappingEncoder 上获得额外的选项 immediateSync

【讨论】:

  • 谢谢,马丁。这些天会做这个。感谢您维护我们和项目。
  • 这个outputStream是一个ResilientFileOutputStream,它不是从FileOutputStream扩展而来的,所以它没有getFD()方法。
  • 对。我更新了我的答案......但我没有比以前测试更多
  • 啊,杂种。看起来这需要反射才能从 ResilientOutputStreamBase 中提取受保护的 os 字段。
【解决方案3】:

我决定将我的解决方案带给大家。 首先让我澄清一下,这不是 logback 问题,也不是 JRE 问题。这在javadoc 中有所描述,在您遇到文件同步方面的一些老式集成解决方案之前,通常不应该成为问题。

所以这是一个实现立即刷新的 logback appender:

public class ImmediateFileAppender<E> extends RollingFileAppender<E> {

    @Override
    public void openFile(String file_name) throws IOException {
        synchronized (lock) {
            File file = new File(file_name);
            if (FileUtil.isParentDirectoryCreationRequired(file)) {
                boolean result = FileUtil.createMissingParentDirectories(file);
                if (!result) {
                    addError("Failed to create parent directories for [" + file.getAbsolutePath() + "]");
                }
            }

            ImmediateResilientFileOutputStream resilientFos = new ImmediateResilientFileOutputStream(file, append);
            resilientFos.setContext(context);
            setOutputStream(resilientFos);
        }
    }

    @Override
    protected void writeOut(E event) throws IOException {
        super.writeOut(event);
    }

}

这是对应的输出流实用程序类。由于最初应该用于扩展的原始ResilientOutputStreamBase 的某些方法和字段具有打包的访问修饰符,因此我不得不扩展OutputStream,并将ResilientOutputStreamBaseResilientFileOutputStream 的其余部分和未更改的部分复制到这个新的。我只是显示更改后的代码:

public class ImmediateResilientFileOutputStream extends OutputStream {

    // merged code from ResilientOutputStreamBase and ResilientFileOutputStream

    protected FileOutputStream os;

    public FileOutputStream openNewOutputStream() throws IOException {
        return new FileOutputStream(file, true);
    }

    @Override
    public void flush() {
        if (os != null) {
            try {
                os.flush();
                os.getFD().sync(); // this's make sence
                postSuccessfulWrite();
            } catch (IOException e) {
                postIOFailure(e);
            }
        }
    }

}

最后是配置:

<appender name="FOR_INTEGRATION" class="package.ImmediateFileAppender">
    <file>/somepath/for_integration.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
        <fileNamePattern>for_integration.log.%i</fileNamePattern>
        <minIndex>1</minIndex>
        <maxIndex>3</maxIndex>
    </rollingPolicy>
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
        <maxFileSize>5MB</maxFileSize>
    </triggeringPolicy>
    <encoder>
        <pattern>%d{HH:mm:ss.SSS} - %msg%n</pattern>
        <immediateFlush>true</immediateFlush>
    </encoder>
</appender>

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-04-06
    • 2013-08-07
    • 1970-01-01
    • 2013-12-23
    • 2023-03-30
    • 2022-11-10
    • 2019-01-19
    • 2014-02-13
    相关资源
    最近更新 更多