logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Park <simon_park_m...@yahoo.co.uk>
Subject Re: Time and Size based rolling (using log4j companions extras)
Date Wed, 06 Jul 2011 18:59:28 GMT
Hi Olivier,

Assuming that you're sticking with Log4J, you could perhaps try out the 
TimeAndSizeRollingAppender available at www.simonsite.org.uk.  This Appender is 
in production use in at least one large investment bank where it is deployed in 
several configurations, including threaded applications that can easily log 100s 
of MB per minute.

Best Regards,

Simon




________________________________
From: Olivier Jaquemet <olivier.jaquemet@jalios.com>
To: log4j-user@logging.apache.org
Sent: Tue, 5 July, 2011 16:28:38
Subject: Time and Size based rolling (using log4j companions extras)

Hi,

I am trying to get log4j to roll log file on a timely basis (weekly), while also 
splitting log files which grow too big.
Exactly the same thing provided in logback through SizeAndTimeBasedFNATP :
http://logback.qos.ch/manual/appenders.html#SizeAndTimeBasedFNATP

In order to do that I tried 2 different approach, both fails for different 
reasons.

1. Using a TimeBasedRollingPolicy, with an added SizeBasedTriggeringPolicy
Problem: The SizeBasedTriggeringPolicy does indeed request a rollover, but 
because the filename does not change for the TimeBasedRollingPolicy, nothing 
happens (even though the rollover() method is called).

<appender name="ROLLFILE" class="org.apache.log4j.rolling.RollingFileAppender">
<rollingPolicy class="org.apache.log4j.rolling.TimeBasedRollingPolicy">
<param name="FileNamePattern" value="/wombat/folder/foo.%d{yyyy-MM-dd}.gz"/>
</rollingPolicy>
<triggeringPolicy class="org.apache.log4j.rolling.SizeBasedTriggeringPolicy">
<param name="MaxFileSize" value="10240"/>
</triggeringPolicy>
</appender>

This simple approach fails because I am not using the TimeBasedRollingPolicy as 
it was conceived. I can understand that, so let just forget about this one and 
just move on to the second approach...

2. Using a FixedWindowRollingPolicy, and using a composite triggering policy 
with both a TimeBasedRollingPolicy and a SizeBasedTriggeringPolicy.

Problem : The TimeBasedRollingPolicy does not work when used as a 
TriggeringPolicy. The implementation of isTriggeringEvent(..) depends on a 
'nextCheck' variable which is only updated through rollover() method (not 
invoked because it is not being used as the the rolling policy).
-> If TimeBasedRollingPolicy implements the TriggeringPolicy, I think it should 
support being used only this way.
Also, as a side note, it would have been nice if the CompositeTriggeringPolicy 
java was providing an XML example of the declaration, I add to find the commit 
of this class to know how to use it (and indicate that warnings during the XML 
parsing is normal, or better find a way to remove those warnings).

<appender name="ROLLFILE" class="org.apache.log4j.rolling.RollingFileAppender">
<rollingPolicy class="org.apache.log4j.rolling.FixedWindowRollingPolicy">
<param name="ActiveFileName" value="/wombat/folder/foo.log"/>
<param name="FileNamePattern" value="/wombat/folder/foo.%i.log.gz"/>
</rollingPolicy>

<triggeringPolicy class="org.apache.log4j.rolling.CompositeTriggeringPolicy">
<triggeringPolicy class="org.apache.log4j.rolling.TimeBasedRollingPolicy">
<param name="FileNamePattern" value="%d{yyyy-MM-dd}"/>
</triggeringPolicy>
<triggeringPolicy class="org.apache.log4j.rolling.SizeBasedTriggeringPolicy">
<param name="MaxFileSize" value="10240"/>
</triggeringPolicy>
</triggeringPolicy>
</appender>

Is there any log4j commiter that could check my analysis and potentially provide 
a fix/workaround ?
Otherwise, is there any other way to do time+size rolling ?

Any help is really appreciated.
Olivier

-- @OlivierJaquemet



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message