Thank you Simon, I will have a look at that as it is exactly what I need ! It looks very promising and your comparison table is perfect. Really fantastic job !
Best regards, Olivier PS : I had not remarked your site in any of my search results. Shame on me. On 06/07/2011 20:59, Simon Park wrote:
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<[email protected]> To: [email protected] 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: [email protected] For additional commands, e-mail: [email protected]
-- Olivier Jaquemet<[email protected]> Ingénieur R&D Jalios S.A. - http://www.jalios.com/ @OlivierJaquemet +33970461480 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
