You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Cheryl Mrozienski (JIRA)" <ji...@apache.org> on 2016/07/12 21:44:20 UTC

[jira] [Created] (LOG4J2-1462) defer creation/open of RollingFileAppender log files when level="OFF"

Cheryl Mrozienski created LOG4J2-1462:
-----------------------------------------

             Summary: defer creation/open of RollingFileAppender log files when level="OFF"
                 Key: LOG4J2-1462
                 URL: https://issues.apache.org/jira/browse/LOG4J2-1462
             Project: Log4j 2
          Issue Type: Improvement
          Components: Appenders
    Affects Versions: 2.3
            Reporter: Cheryl Mrozienski
            Priority: Minor


I am currently using Log4j version 2.3, but I might be able to update to a newer version if that would help.

I have a log4j2.xml file containing more than thirty RollingFileAppenders (one per product component).  Most of these RollingFileAppenders will not be written to until the user turns on logging via our product’s user interface.  By default, the AppenderRefs that reference these RollingFileAppenders have the “level” attribute set to a value of “OFF”.  Once the user turns on logging from the user interface, the “level” attribute will be updated with a value of “INFO”, “DEBUG”, etc.  And, once the updated log4j2.xml file is persisted, the code will then call LoggerContext.reconfigure() to get Log4j to read in the new log4j2.xml file, so the new log levels take effect.

I'd like to request a fix and/or a new "deferCreate" or "deferOpen" configuration option be added to Log4j to defer log file creation when nothing will initially write to the file (e.g. all references to the Appender have a level of “OFF”)?  Having lots of zero sized log files is not that big of an issue, although not completely optimal.  However, having too many open file handles that are not doing anything, could potentially become an issue.  Note that I do not have control over the number of Appenders configured for the product.  Each product component team contributes its Appender and Loggers to log4j2.xml.

To work around the open file handle issue at server startup time, I am currently using the Log4j2 private core API calls to loop through the AppenderRefs to determine which ones are “OFF”, and then I’m calling the RollingFileAppender.stop() method to close the output stream.  If anyone has any ideas that would avoid creating and opening the log files in the first place, I’d love to hear your thoughts.

Thanks for considering this request.

p.s. for reference, the relevant log4j2.xml snippets follow:

<Appenders>
    <RollingFile
      fileName="${sys:com.compellent.msaserviceDir}/etc/compservices/debuglogs/Scheduler/Scheduler.debuglog"
      filePattern="${sys:com.compellent.msaserviceDir}/etc/compservices/debuglogs/Scheduler/Scheduler_%i.debuglog.gz"
      name="debug.Scheduler">
      <PatternLayout>
        <Pattern>%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p {%C:%M} [%marker] (%t) - %msg%n</Pattern>
      </PatternLayout>
      <Policies>
        <SizeBasedTriggeringPolicy size="50 MB"/>
      </Policies>
      <DefaultRolloverStrategy max="10"/>
      <Filters>
        <MarkerFilter marker="Scheduler" onMatch="ACCEPT" onMismatch="DENY"/>
      </Filters>
    </RollingFile>
</Appenders>

<Loggers>
    <Logger includeLocation="true" level="TRACE" name="debugLogger">
      <AppenderRef level="DEBUG" ref="debug.ModuleManager"/>
      <AppenderRef level="OFF" ref="debug.Scheduler"/>
    </Logger>
</Loggers>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org