Log4j 2
  1. Log4j 2
  2. LOG4J2-267

FastRollingFileAppender doesn't work well with TimeBasedTriggeringPolicy

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta6
    • Fix Version/s: 2.0-beta8
    • Component/s: Appenders
    • Labels:
      None
    • Environment:

      Win7 SP1 64bit + JDK 6u43 64bit

      Description

      The below configuration file doesn't deliver correct rollover. As soon as logging starts, the log file is rolled over with this date "1970-01-01". The same configuration work fine with RollingFile appender.
      <configuration>
      <appenders>
      <FastRollingFile name="LogFile" fileName="log/ui-selenium-tests.log" append="false"
      filePattern="log/ui-selenium-tests.%d

      {yyyy-MM-dd}

      .log">
      <ThresholdFilter level="INFO" onMatch="ACCEPT" onMismatch="DENY"/>
      <PatternLayout pattern="%d %p [%c.%M():%L] - %m%n"/>
      <Policies>
      <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
      </Policies>
      <DefaultRolloverStrategy/>
      </FastRollingFile >
      </appenders>
      <loggers>
      <root level="TRACE">
      <appender-ref ref="LogFile"/>
      </root>
      </loggers>
      </configuratio

      1. LOG4J2-267.patch
        1 kB
        Thomas Neidhart

        Issue Links

          Activity

          Hide
          ilynaf added a comment -

          Verified on beta 8

          Show
          ilynaf added a comment - Verified on beta 8
          Hide
          Remko Popma added a comment -

          Fixed in revision 1498044. Please verify and close.

          Show
          Remko Popma added a comment - Fixed in revision 1498044. Please verify and close.
          Hide
          Thomas Neidhart added a comment -

          You are right, I did not look carefully enough.
          Thinking about it, it is probably better to do the same thing as in the RollingFileManager also in the FastRollingFileManager: instead of deleting the file if we are not appending, force a create new. In this case the lastModified method should return the correct timestamp.

          Show
          Thomas Neidhart added a comment - You are right, I did not look carefully enough. Thinking about it, it is probably better to do the same thing as in the RollingFileManager also in the FastRollingFileManager: instead of deleting the file if we are not appending, force a create new. In this case the lastModified method should return the correct timestamp.
          Hide
          Remko Popma added a comment - - edited

          Thomas, you also provided a patch for RollingFileManager, but I don't see why this is needed as this manager creates the file just before gettings its LastModified time (as opposed to the Fast version which may delete the old file).

          Your patch looks fine for FastRollingFileManager (still need to do a quick test before I commit), but I think RollingFileManager is fine as is, or am I missing something?

          Show
          Remko Popma added a comment - - edited Thomas, you also provided a patch for RollingFileManager, but I don't see why this is needed as this manager creates the file just before gettings its LastModified time (as opposed to the Fast version which may delete the old file). Your patch looks fine for FastRollingFileManager (still need to do a quick test before I commit), but I think RollingFileManager is fine as is, or am I missing something?
          Hide
          Remko Popma added a comment -

          Thanks Thomas! I'll take a look at your patch(es) as soon as I can.

          Show
          Remko Popma added a comment - Thanks Thomas! I'll take a look at your patch(es) as soon as I can.
          Hide
          Thomas Neidhart added a comment -

          The attached patch fixes the problem. In case the file was newly created (append=false), the initial time for the rollover was set to 0 (= January 1, 1970). In that case the initial time is set to the current time.

          Show
          Thomas Neidhart added a comment - The attached patch fixes the problem. In case the file was newly created (append=false), the initial time for the rollover was set to 0 (= January 1, 1970). In that case the initial time is set to the current time.
          Hide
          Shahbaz Chaudhary added a comment - - edited

          I see the same thing, except I get date "12-31-1969"

          EDIT:
          My error occurs on SizeBasedTriggeringPolicy (comes from an example on docs page):
          <Policies>
          <TimeBasedTriggeringPolicy />
          <SizeBasedTriggeringPolicy size="500 MB" />
          </Policies>

          Show
          Shahbaz Chaudhary added a comment - - edited I see the same thing, except I get date "12-31-1969" EDIT: My error occurs on SizeBasedTriggeringPolicy (comes from an example on docs page): <Policies> <TimeBasedTriggeringPolicy /> <SizeBasedTriggeringPolicy size="500 MB" /> </Policies>

            People

            • Assignee:
              Remko Popma
              Reporter:
              ilynaf
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development