[
https://issues.apache.org/jira/browse/KAFKA-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15303544#comment-15303544
]
Ewen Cheslack-Postava commented on KAFKA-2394:
----------------------------------------------
[~cotedm] If there are risks with DailyRollingFileAppender, I definitely think
its good to clean it up. One thing to watch out for is that this is, in some
sense, a public API/settings. I don't think we've been clear about
compatibility for log settings but I suspect a large number of users still rely
on our defaults. What do we need to do re: documentation and compatibility?
Seems like a simple docs update could take care of most of the issues --
there's no good migration story for changes like this, but they probably at
least need to be clearly documented. Might also be worth a ping on the mailing
list about the change -- I suspect nobody will object, but for stuff like this
its a good idea to try to make a best effort to notify people of the change so
they have a chance to object if they really need to.
> 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)
