Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log4j fails to honor lastModifiedTime #2937

Closed
feujun opened this issue Sep 10, 2024 · 2 comments · Fixed by #2941
Closed

Log4j fails to honor lastModifiedTime #2937

feujun opened this issue Sep 10, 2024 · 2 comments · Fixed by #2941
Assignees
Labels
bug Incorrect, unexpected, or unintended behavior of existing code configuration Affects the configuration system in a general way
Milestone

Comments

@feujun
Copy link

feujun commented Sep 10, 2024

Description

When using a monitorInterval setting on a remote/http log4j.xml the reconfigure-thread does not update the lastModifiedTime of the configuration source and reconfigures the loggers every time.

Configuration

Version: 2.23 and 2.24

Operating system: Windows 10

JDK: AdoptOpenJDK 21

Logs

log.txt

Reproduction

I don't really have a completely isolated test. The problem does not occur when using a file-based log-config, so you need something like a webserver.

My test-setup looks like this:

Main

public static void main(String[] args) throws Exception {
  System.setProperty("log4j2.debug", "true");
  System.setProperty("log4j2.Configuration.allowedProtocols","http,https,file,jar");
		
    Configurator.reconfigure(URI.create("http://sfs00053/configs/t7/client/testlog.xml"));

    new Thread(() -> {
      while (true) {
      try {
        LogManager.getLogger().error("hello");
        TimeUnit.SECONDS.sleep(5);
      } catch (InterruptedException e) {
        throw new RuntimeException(e);
      }
    }
  }).start();
}

Log-Config

<?xml version="1.0" encoding="UTF-8" ?>
<Configuration monitorInterval="10">
  <Appenders>

    <Console name="STDOUT" target="SYSTEM_OUT">
      <PatternLayout pattern="%d | %-5p | %c | %m%n" />
    </Console>
  </Appenders>
  <Loggers>

    <Root level="DEBUG">
      <AppenderRef ref="STDOUT" />
    </Root>
  </Loggers>
</Configuration>

Steps to reproduce

  1. Change the log4j.xml-location in the main to your own location
  2. Start the main. log4j2 should configure itself with the given log-config and log every 5 seconds
  3. Change the file on the webserver so the lastModified of the log-config is newer than the one log4j2 knows (e.g. by touch testlog.xml)
  4. log4j2 will now reconfigure every 10 seconds and not only once because it doesn't honor the new lastModified

See also the attached log. I changed the file on the webserver after the first watchmonitor run. After that it reconfigured itself every time.

I hope I filled out this issue correctly. If something's missing please let me know :)

@ppkarwasz ppkarwasz self-assigned this Sep 10, 2024
@ppkarwasz ppkarwasz changed the title Log4J2 failing to honor monitorInterval Log4j fails to honor lastModifiedTime Sep 10, 2024
ppkarwasz added a commit that referenced this issue Sep 10, 2024
The `HttpWatcher` didn't propagate the observed
last modification time back to the configuration.
As a result, each new configuration was already
deprecated when it started and the reconfiguration
process looped.

Closes #2937
@ppkarwasz
Copy link
Contributor

@feujun,

Nice catch! Effectively, if the configuration location is an http or https URI, reconfiguration will occur every monitorInterval seconds after the first change to the file.

This will be fixed in 2.24.1.

@feujun
Copy link
Author

feujun commented Sep 11, 2024

That sounds great, thank you very much :)

@vy vy added bug Incorrect, unexpected, or unintended behavior of existing code configuration Affects the configuration system in a general way labels Sep 12, 2024
@vy vy added this to the 2.24.1 milestone Sep 12, 2024
ppkarwasz added a commit that referenced this issue Sep 18, 2024
The `HttpWatcher` didn't propagate the observed
last modification time back to the configuration.
As a result, each new configuration was already
deprecated when it started and the reconfiguration
process looped.

Closes #2937

Rewrite Jetty tests using WireMock

Closes #2813
ppkarwasz added a commit that referenced this issue Sep 22, 2024
The `HttpWatcher` didn't propagate the observed
last modification time back to the configuration.
As a result, each new configuration was already
deprecated when it started and the reconfiguration
process looped.

Closes #2937

Rewrite Jetty tests using WireMock

Closes #2813
ppkarwasz added a commit that referenced this issue Sep 22, 2024
The `HttpWatcher` didn't propagate the observed
last modification time back to the configuration.
As a result, each new configuration was already
deprecated when it started and the reconfiguration
process looped.

Closes #2937

Rewrite Jetty tests using WireMock

Closes #2813

Co-authored-by: Volkan Yazıcı <[email protected]>
ppkarwasz added a commit that referenced this issue Sep 23, 2024
The `HttpWatcher` didn't propagate the observed
last modification time back to the configuration.
As a result, each new configuration was already
deprecated when it started and the reconfiguration
process looped.

Closes #2937

Rewrite Jetty tests using WireMock

Closes #2813

Co-authored-by: Volkan Yazıcı <[email protected]>
ppkarwasz added a commit that referenced this issue Oct 1, 2024
The `HttpWatcher` didn't propagate the observed
last modification time back to the configuration.
As a result, each new configuration was already
deprecated when it started and the reconfiguration
process looped.

Closes #2937

Rewrite Jetty tests using WireMock

Closes #2813

Co-authored-by: Volkan Yazıcı <[email protected]>
ppkarwasz added a commit that referenced this issue Oct 2, 2024
The `HttpWatcher` didn't propagate the observed
last modification time back to the configuration.
As a result, each new configuration was already
deprecated when it started and the reconfiguration
process looped.

Closes #2937

Rewrite Jetty tests using WireMock

Closes #2813

Co-authored-by: Volkan Yazıcı <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Incorrect, unexpected, or unintended behavior of existing code configuration Affects the configuration system in a general way
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants