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

          ilynaf created issue -
          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>
          Remko Popma made changes -
          Field Original Value New Value
          Assignee Remko Popma [ remkop@yahoo.com ]
          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.
          Thomas Neidhart made changes -
          Attachment LOG4J2-267.patch [ 12589264 ]
          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
          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
          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.
          Remko Popma made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Remko Popma made changes -
          Link This issue is duplicated by LOG4J2-271 [ LOG4J2-271 ]
          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.
          Remko Popma made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Remko Popma made changes -
          Fix Version/s 2.0-beta8 [ 12324575 ]
          ilynaf made changes -
          Comment [ Verified on beta 8 ]
          Hide
          ilynaf added a comment -

          Verified on beta 8

          Show
          ilynaf added a comment - Verified on beta 8
          ilynaf made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open In Progress In Progress
          32d 2h 34m 1 Remko Popma 29/Jun/13 11:44
          In Progress In Progress Resolved Resolved
          13h 58m 1 Remko Popma 30/Jun/13 01:43
          Resolved Resolved Closed Closed
          67d 2h 1 ilynaf 05/Sep/13 03:43

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development