Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-8957

The AMQ Broker cannot get to output to log/artemis.log if the bin/artemis command is executed when log/artemis.log is zero in size.

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Undefined Undefined
    • None
    • AMQ 7.10.2.GA
    • logging
    • None
    • False
    • None
    • False
    • Workaround Exists

      • The AMQ Broker cannot get to output to log/artemis.log if the bin/artemis command is executed when log/artemis.log is zero in size.
      • Steps to Reproduce:
        1. Ensure log/artemis.log has a file size of zero, which can occur naturally after file rolling.
          • For example, the following log4j2.properties replaces the log file on a rolling basis every minute
            # Log file appender
            appender.log_file.type = RollingFile
            appender.log_file.name = log_file
            appender.log_file.fileName = ${sys:artemis.instance}/log/artemis.log
            appender.log_file.filePattern = ${sys:artemis.instance}/log/artemis.log.%d{yyyy-MM-dd-HHmmss}
            appender.log_file.layout.type = PatternLayout
            appender.log_file.layout.pattern = %d %-5level [%logger] %msg%n
            appender.log_file.policies.type = Policies
            appender.log_file.policies.cron.type = CronTriggeringPolicy
            appender.log_file.policies.cron.schedule = 0 0/1 * * * ?
            appender.log_file.policies.cron.evaluateOnStartup = true
            
        2. Execute any bin/artemis command within the AMQ Broker instance directory immediately after replacing the log file by rolling
          • ==> Then the AMQ Broker cannot output to log/artemis.log. For example, if the AMQ Broker is stopped at this time, nothing will be output to log/artemis.log that should be output.
          • ==> As long as I've investigated when the bin/artemis command is executed, log4j2 runs internally and replaces the log/artemis.log file. (This does not occur if the file size is non-zero.). So the previous log/artemis.log log file is virtually deleted and the AMQ broker is unable to output logs to the correct log/artemis.log
      • Workarounds:
        • Use an alternative Log4j2 configuration file that does not utilize log/artemis.log.
          • This can be done by setting the JAVA_ARGS_APPEND environment variable to a different Log4j2 configuration file (even an empty one is acceptable).
          • Example:
            env JAVA_ARGS_APPEND="-Dlog4j.configurationFile=path/to/log4j2.properties" ./bin/artemis queue stat
        • Increase the log/artemis.log file size before executing the command.
          • For instance, use echo to add content to the file, preventing it from being zero-sized.
          • Example:
            echo "foo" >> log/artemis.log ; ./bin/artemis queue stat
        • Use the bin/artemis command from the AMQ installation directory rather than the AMQ Broker instance directory.
          • This approach avoids using Log4j2 and thus circumvents the issue. However, some commands that must be run from the Broker instance directory (e.g., user list) will not be available.
      • Problem
        • I believe there is a problem with using AMQ Broker's log4j2 when executing CLI commands from the AMQ Broker instance directory. There is no reason to use log4j2 the server's log output mechanism in client commands.
        • The log4j2 log output mechanism of the AMQ Broker server should not be used in executing client commands.

              Unassigned Unassigned
              rhn-support-tyamashi Tomonari Yamashita
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: