Uploaded image for project: 'Log4j 2'
  1. Log4j 2
  2. LOG4J2-267

FastRollingFileAppender doesn't work well with TimeBasedTriggeringPolicy

    Details

    • Type: Bug
    • Status: Closed
    • Priority: 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
          shahbazc@gmail.com 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
          shahbazc@gmail.com 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>
          Hide
          tn 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
          tn 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
          remkop@yahoo.com Remko Popma added a comment -

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

          Show
          remkop@yahoo.com Remko Popma added a comment - Thanks Thomas! I'll take a look at your patch(es) as soon as I can.
          Hide
          remkop@yahoo.com 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
          remkop@yahoo.com 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
          tn 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
          tn 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
          remkop@yahoo.com Remko Popma added a comment -

          Fixed in revision 1498044. Please verify and close.

          Show
          remkop@yahoo.com Remko Popma added a comment - Fixed in revision 1498044. Please verify and close.
          Hide
          ilynaf ilynaf added a comment -

          Verified on beta 8

          Show
          ilynaf ilynaf added a comment - Verified on beta 8

            People

            • Assignee:
              remkop@yahoo.com Remko Popma
              Reporter:
              ilynaf ilynaf
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development