[
https://issues.apache.org/jira/browse/KAFKA-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15302104#comment-15302104
]
ASF GitHub Bot commented on KAFKA-2394:
---------------------------------------
GitHub user cotedm opened a pull request:
https://github.com/apache/kafka/pull/1434
KAFKA-2394: move to RollingFileAppender by default for log4j
This PR sets up the default max log size to be about 1GB. That default
should probably be vetted.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/cotedm/kafka trunk
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/kafka/pull/1434.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 #1434
----
commit 6eab7890db19cf0d873530278b8cd43877063f69
Author: Dustin Cote <dus...@confluent.io>
Date: 2016-05-26T13:52:35Z
move to RollingFileAppender by default for log4j
----
> 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: jin xing
> Priority: Minor
> Labels: newbie
> 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)
