[
https://issues.apache.org/jira/browse/KAFKA-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389617#comment-15389617
]
ASF GitHub Bot commented on KAFKA-2394:
---------------------------------------
GitHub user cotedm opened a pull request:
https://github.com/apache/kafka/pull/1652
KAFKA-2394: move to RollingFileAppender by default for log4j
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/cotedm/kafka KAFKA-2394
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/kafka/pull/1652.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1652
----
commit 31a565b31a99567327b774045fbf726f5a2d1812
Author: Dustin Cote <dus...@confluent.io>
Date: 2016-07-22T14:37:53Z
update log4j.properties to use RollingFileAppender
----
> Use RollingFileAppender by default in log4j.properties
> ------------------------------------------------------
>
> Key: KAFKA-2394
> URL: https://issues.apache.org/jira/browse/KAFKA-2394
> Project: Kafka
> Issue Type: Bug
> Reporter: Jason Gustafson
> Assignee: Dustin Cote
> Priority: Minor
> Labels: newbie
> Fix For: 0.11.0.0
>
> Attachments: log4j.properties.patch
>
>
> The default log4j.properties bundled with Kafka uses ConsoleAppender and
> DailyRollingFileAppender, which offer no protection to users from spammy
> logging. In extreme cases (such as when issues like KAFKA-1461 are
> encountered), the logs can exhaust the local disk space. This could be a
> problem for Kafka adoption since new users are less likely to adjust the
> logging properties themselves, and are more likely to have configuration
> problems which result in log spam.
> To fix this, we can use RollingFileAppender, which offers two settings for
> controlling the maximum space that log files will use.
> maxBackupIndex: how many backup files to retain
> maxFileSize: the max size of each log file
> One question is whether this change is a compatibility concern? The backup
> strategy and filenames used by RollingFileAppender are different from those
> used by DailyRollingFileAppender, so any tools which depend on the old format
> will break. If we think this is a serious problem, one solution would be to
> provide two versions of log4j.properties and add a flag to enable the new
> one. Another solution would be to include the RollingFileAppender
> configuration in the default log4j.properties, but commented out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
