Develop Reference

log4j gets stuck at a maximum number of 13 files even though the configured limit is 50?

This is the log4j properties file we are using, could you please explain why the limit for number of files is stuck at 13 instead of 50 as defined in "maxIndex" Property?
# Root logger option
log4j.rootLogger=INFO,file,stdout
log4j.logger.com.cisco.assurance=DEBUG, file
# Redirect log messages to console
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.Threshold=DEBUG
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd'T'HH:mm:ss.SZ} %-5p %m%n
# Redirect log messages to a log file
log4j.appender.file=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.file.rollingPolicy=org.apache.log4j.rolling.FixedWindowRollingPolicy
log4j.appender.file.triggeringPolicy=org.apache.log4j.rolling.SizeBasedTriggeringPolicy
log4j.appender.file.rollingPolicy.FileNamePattern=/var/log/smeu/AssuranceMS-%i.log.gz
log4j.appender.file.rollingPolicy.ActiveFileName=/var/log/smeu/AssuranceMS.log
log4j.appender.file.triggeringPolicy.MaxFileSize=204800000
log4j.appender.file.rollingPolicy.maxIndex=50
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d [%t] %-5p (%F:%L) - %m%n
log4j.appender.file.Threshold=DEBUG

From the API of org.apache.log4j.rolling.FixedWindowRollingPolicy, it is reduced by design to 12 backups plus the current one, so 13 maximum.
You can look at it : https://logging.apache.org/log4j/extras/apidocs/org/apache/log4j/rolling/FixedWindowRollingPolicy.html

This is happening because large window size is discouraged and the maxIndex is automatically reduced to 12. It is well documented here.
Given that this rollover algorithm requires as many file renaming operations as the window size, large window sizes are discouraged. The current implementation will automatically reduce the window size to 12 when larger values are specified by the user.

log4j grok with pipes fail

i need to format a grok input for the next log format
[#|2017-10-12T07:40:16.232-0700|INFO|sun-appserver2.1|RugDaemonCMLog|_ThreadID=17;_ThreadName=Thread-25;|Wake Up!!#]
[#|2017-10-12T07:40:16.241-0700|INFO|sun-appserver2.1|RugDaemonCMLog|_ThreadID=17;_ThreadName=Thread-25;|--Don't have a work in batch|#]
[#|2017-10-12T07:40:16.241-0700|INFO|sun-appserver2.1|RugDaemonCMLog|_ThreadID=17;_ThreadName=Thread-25;|go to sleep!|#]
[#|2017-10-12T07:40:16.567-0700|INFO|sun-appserver2.1|RugProject|_ThreadID=16;_ThreadName=Thread-23;| sleep---|#]
[#|2017-10-12T07:40:16.568-0700|INFO|sun-appserver2.1|RugProject|_ThreadID=16;_ThreadName=Thread-23;|Sending Mail|#]
[#|2017-10-12T07:40:16.569-0700|INFO|sun-appserver2.1|RugProject|_ThreadID=16;_ThreadName=Thread-23;|--lookup--|#]
i have the following sintax in my log4j file
log4j.appender.file.datePattern='.'yyyy-MM-dd_HH_mm
log4j.appender.file.MaxFileSize=10MB
log4j.appender.file.MaxBackupIndex=100
log4j.appender.file.encoding=UTF-8
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{dd-MM-yyyy HH:mm:ss} %-5p %c{1}:%L - %m%n
in the debugger online i'm trying this format
%{TIMESTAMP_ISO8601:logdate}\|%{LOGLEVEL:loglevel}|%{WORD:caller}\|%{NONNEGINT:line} - %{GREEDYDATA:message}$
that format parse the date and the log level info, but not the caller and the thread information

Use this:
%{TIMESTAMP_ISO8601:logdate}\|%{LOGLEVEL:loglevel}\|%{DATA:caller}\|%{DATA:line}\|_ThreadID=%{DATA:threadid};_ThreadName=%{DATA:threadname}\|%{GREEDYDATA:message}\|%{GREEDYDATA:fin}$

Logback string length

I'm using logback to log to a rolling file in my Spring Boot service. In one of my classes, I am attempting to log a really long string (a string value of a very large object array that can have tens of thousands of elements).
log.info(str);
The above does not print, probably because the value of str is a very very long string.
//logback truncates the list - to preserve this we should record it in an audit table
String rl = String.valueOf(reptIdList);
String truncRlStr = rl.substring(0, Math.min(rl.length(), 100));
log.info(truncRlStr);
The above does print. Probably because I'm truncating the very long string to 100 characters.
There is probably a limit to the length of the string in logback - is there a way to set it to maximum string length? I notice that there is no limitation on string length when logging into the console.
Thanks for any advice.

I know it is an old question now and OS moved on in her/his life, but it would be useful to someone coming to this thread.
You can limit the number of characters logback would log using: %.-<limit>msg
e.g. to limit the number of characters to 100:
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<layout class="ch.qos.logback.classic.PatternLayout">
<Pattern>
%.-30msg%n
</Pattern>
</layout>
</appender>
PS: I tested this using ch.qos.logback library

How do I show all whitespace log4j supplied messages?

I supply a formatted java string with significant whitespace
String.format("%1$12s %2$15s", "someString", "anotherOne");
to be logged using the following conversion pattern in log4j
<param name="ConversionPattern" value="%d{ISO8601} %-5p [%t] %c{1} %m%n" />
In the logs, I receive the variable with just a single preceding whitespace.
... PatternStuff ... someString anotherOne
slf4j version 1.7.3
log4j version 1.2.14
Is it possible to show the whitespace added by String.format? Some other conversion pattern variable other than %m?

My workplace has an internal web-based logviewer that quickly gives developers a way to access the contents of log files. We have the ability to print logs out in a generated webpage or to download the log. When I view them in the browser, the spaces are collapsed (because of standard HTML output). However, when I download the log files, they appear with the given formatting! Sorry for the confusion.

Log4J: cannot change bufferSize with bufferedIO = true at FileAppender

I think I run into a problem using log4j. I'm trying to enable bufferedio, but the default buffer size of 8KB is too big for my current needs
<appender name="MyAppender" class="org.apache.log4j.FileAppender">
<param name="bufferedIO" value="true"/>
<param name="bufferSize" value="512"/>
<param name="Append" value="true"/>
<param name="File" value="C:/MyMonitor.log"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{dd/MM/yyyy HH:mm:ss}|%m%n"/>
</layout>
</appender>
<logger name="com.mypackage.MyMonitor">
<level value="debug"/>
<appender-ref ref="MyAppender"/>
</logger>
I've tried different sizes for the buffer but the writing to the file only happens when the buffer reaches 8KB.
I cannot find any bug in Log4J describing this problem, even when I could find another guy who had the same problem (without any solution).
Enabling the Log4J debug shows that my appender has the proper buffersize, so I think that no one is overwriting my configuration.
Any idea of what am I doing wrong? Is it really a bug or limitation in Log4J?
Thanks.

I've noticed, that you wrote bufferedIO starting from lowercase and BufferSize starting from capital. Java is case-sensitive by default, so please make all your parameters look like in the constructor (bufferSize should be lowercased).
Also as I know FileAppender is deprecated. WriterAppender is a closest replacement.

log4j 1.2.17
Dive to the source code, I find DailyRollingFileAppender use java.io.OutputStreamWriter to write characters to log file. Threre is a buffer in OutputStreamWriter. The size is 8k(8192) in jdk 1.7
Because of this second cache, you will find : If you set log4j.appender.file.bufferSize=8192, even the log data is more than 8192 ( <=8192*2 ), there is no data in log file. The reason is the second cache(OutputStreamWriter) hold the first 8192 chars and DailyRollingFileAppender cache hold the remaining.
JDK API java.io.OutputStreamWriter:
Each invocation of a write() method causes the encoding converter to be invoked on the given character(s). The resulting bytes are accumulated in a buffer before being written to the underlying output stream. The size of this buffer may be specified, but by default it is large enough for most purposes. Note that the characters passed to the write() methods are not buffered.