I am using the following in logback.xml. This is keeping only 21 files and removing older log files. Can anyone please suggest how the file removal can be stopped?
<appender name="MY_UPDATES_APPENDER"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<!--See also http://logback.qos.ch/manual/appenders.html#RollingFileAppender -->
<File>logs/upilogs/upi-app.log
</File>
<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
<fileNamePattern>logs/upilogs/my-app.%i.log
</fileNamePattern>
<minIndex>1</minIndex>
<maxIndex>50</maxIndex>
</rollingPolicy>
<triggeringPolicy
class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
<maxFileSize>200MB</maxFileSize>
</triggeringPolicy>
<encoder>
<Pattern>%d %X %-5level %logger{36} - %msg%n%ex</Pattern>
</encoder>
</appender>
This is a feature of logback. Quoting from the linked URL
Given that the fixed window rolling policy requires as many file
renaming operations as the window size, large window sizes are
strongly discouraged. When large values are specified by the user, the
current implementation will automatically reduce the window size to
20.
Related
I have an appender configured like...
<appender name="DAILY_ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>logs/dm.log</File>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<FileNamePattern>logs/dm.%d{yyyyMMdd}.log</FileNamePattern>
</rollingPolicy>
<encoder>
<pattern>%m%n</pattern>
</encoder>
</appender>
...
<root level="info">
<appender-ref ref="DAILY_ROLLING" />
<appender-ref ref="SYSLOG" />
</root>
...which typically has the effect of logging current data to the dm.log file and everyday at midnight rolling over the dm.log into a file named for the date, dm.20130205.log. Yesterday, however, for the first time ever, this rollover did not occur. My dm.log file now has 2 days worth of data and I am wondering what went wrong? I expected to find a RolloverFailure or some indication of what went wrong to be laying in the dm.log file but there is nothing there.
Where do I look to figure out what went wrong in logback? I have never seen this mechanism fail in either logback or log4j.
Try adding:
-Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener
Or event implementing your own status listener. Then try configuring a file roll every 10 seconds, in a test system, and leave it to soak test.
It might well be a NAS issue. We've had our NAS fail silently in hard to detect ways. Also if the file roll in is in the middle of the night, and it's an overnight batch processing system then the NAS load can be high at that time.
What version of logback are you using?
Edit: A the rollover could be skipped if the rename of the file fails. In my own code I would retry this, but in RenameUtil.rename() logback will just warn you via the status listener.
I am using c3p0 (0.9.1.2) version and after a hour or so I see numUnclosedOrphanedConnections keep increasing slowly like 1 per hour. c3p0 docs said that
numUnclosedOrphanedConnections will only be non-zero following a call
to softReset(). It represents the number of Connections that were
checked out when a soft reset occurred and were therefore silently
excluded from the pool, and which remain unclosed by the client
application.
Why does c3p0 doing soft reset? My c3p0 settings is like
initialPoolSize=1
minPoolSize=1
maxPoolSize=100
maxIdleTime=60
checkoutTimeout=5000
testConnectionOnCheckin=true
Thanks Steve for helping me fixing it. This is how I did it.
Enable Debug level logging for c3po:
<logger name="com.mchange" additivity="false">
<level value="DEBUG" />
<appender-ref ref="C3p0Appender" />
</logger>
c3p0 settings:
debugUnreturnedConnectionStackTraces=true
# 30 sec is enough for me but you should change it for your case
unreturnedConnectionTimeout=30
And the keyword to search inside c3p0 log file is: "Overdue resource check-out "
This logging is only enable in the trunk version of c3p0. It should be there in pre6 release.
I saw these in a template configuration file:
<property>
<name>mapred.map.tasks</name>
<value>2</value>
<description>The default number of map tasks per job. Typically set
to a prime several times greater than number of available hosts.
Ignored when mapred.job.tracker is "local".
</description>
</property>
...
<property>
<name>mapred.reduce.tasks</name>
<value>1</value>
<description>The default number of reduce tasks per job. Typically set
to a prime close to the number of available hosts. Ignored when
mapred.job.tracker is "local".
</description>
</property>
I couldn't find any other reference, neither online nor in the Hadoop O'Reilly book, as to why these should be prime. Anyone have any ideas?
Thanks.
See HADOOP-5519; this is no longer in the configuration file as there was no (or little) reason for it.
I haven't seen it for at least two versions, and JIRA says it was resolved a couple of years ago.
I would like to use slf4j+logback for logging on an JBossAS7.
Additionaly I have to solve the following requirements:
I need to share one logback configuration / context within multiple deployed applications/EARs
I need to change the logback configuration on runtime without a redeploy/restart of the EARs
make (as much as possible) log entries of the JBoss Server visible inside my logging configuration (e.g. deployment logs, etc...)
What I know now, is that JBoss uses its own logging layer. For architectural reasons, I can not use this. I would like to stick with only SLF4J as Logging-API and Logback as framework.
I would be happy to get some hints, how this could be solved.
Regards,
Lars
Lars,
The only way I can think of to do this would be to write a custom handler. While it's not very well documented at the moment, you can create custom java.util.logging.Handler's. You could write a wrapper in a sense around around the logback's configuration. I think they have a BasicConfigurator or something like that.
You register a custom handler like so:
<custom-handler name="logbackHandler" class="org.jboss.LogbackHandler" module="org.jboss.logback">
<level name="DEBUG"/>
<properties>
<property name="nameOfASetterMethod" value="the value to set" />
</properties>
</custom-handler>
<root-logger>
<level name="INFO"/>
<handlers>
<handler name="CONSOLE"/>
<handler name="FILE"/>
<handler name="logbackHandler"/>
</handlers>
</root-logger>
That said there is probably no real need to do that. The application server logger will log the messages even if you are logging through a different façade. You can set-up different file handlers if you want to write to your own files.
I realize logging in JBoss AS7 could really use some better documentation. I do plan on updating that when I find the time :-) And really I just need to make the time.
I am pretty sure that you can use slf4j+logback for your own applications within JBoss and completely bypass its logging. JBoss will continue logging all of its own log messages to its own logs, but your software will not connect to jboss-logging at all and will have its own logs. I have tried this under JBoss 6; we have not yet tried JBoss 7, so things may be different there, but I doubt it. Just make sure slf4j and logback jars are in your applications' classpaths, and you should be good.
If you search through the System properties available to you, you will find some jboss.* properties that may be useful in your logback configuration for finding a place to put your log files.
Personally, I wish JBoss would switch to using slf4j.
I'm creating a custom logback appender which needs to fall back to another appender in certain situations (typically a failure). What I'm trying to achieve is this :
<configuration>
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<layout class="ch.qos.logback.classic.PatternLayout">
<Pattern>%d{HH:mm:ss.SSS} - %msg%n</Pattern>
</layout>
</appender>
<appender name="MYAPPENDER" class="my.appender.class">
<appender-ref ref="CONSOLE" />
</appender>
<root level="trace">
<appender-ref ref="MYAPPENDER" />
</root>
</configuration>
Now, I've implemented AppenderAttachable in MYAPPENDER and it does seem to work, - the frameworks sets a reference to CONSOLE appender during initialization and I use it all right.
Is it a standard way to go about the case? Is there an alternative to this approach? Ideas?
Yes, support for AppenderAttachable is likely to be preserved in the future.
Have you printed logback's internal status messages? What does StatusManager say?
Update: After the changes made to the question my answer no longer makes any sense. I am leaving it nonetheless because as an investigation tool about logback, logback's internal status messages can be very helpful.