Hi Remko. It even didn't flush after I had written 600 KB to it - only after I had stopped tomcat - but I will doublecheck and provide a testcase then.
I haven't experimented with smaller buffer sizes yet. But I'll look into that too. Thanks for your help. Veit Am 03.02.2016 um 23:28 schrieb Remko Popma: > You mention that RollingRandomAccessFile appender with immediateFlush=false > and a buffer size of 256K did not flush to disk until you logged 600KB. > Looking at the code I don't see how this is possible but you may have found a > bug. Is this reproducible? If so, can you raise a Jira with a small test > program that reproduces the issue? > > Continuing our discussion about workarounds: > > You can use either appender. The performance numbers (random access file > appender being 1.3 - 2 times faster than file appender) are for > immediateFlush=false. I don't have numbers for immediateFlush=true. > > There's a separate attribute for setting the buffer size (for both > appenders). Perhaps a smaller buffer size would flush sooner, have you > experimented with that? > > Remko > > Sent from my iPhone > >> On 2016/02/04, at 0:06, Veit Guna <[email protected]> wrote: >> >> So, If I would like to use a rolling file appender with synchronous logging, >> but _with_ buffering and so _not_ flushing on every event what should >> I use? RollingRandomAccessFile with immediateFlush="true" or the "normal" >> RollingFileAppender :)? Does immediateFlush="true" take the buffer into >> account? >> >> Thanks >> Veit >> >> >> Gesendet: Mittwoch, 03. Februar 2016 um 13:43 Uhr >> Von: "Remko Popma" <[email protected]> >> An: "Log4J Users List" <[email protected]> >> Betreff: Re: Aw: Re: RollingRandomAccessFile and emtpy log file >> Sorry my message was unclear. >> >> RollingRandomAccessFile appender does not _need_ async loggers, it's just >> that if you choose to use async loggers, you will get the side-effect of >> regular flushing in the background. So it achieves your goal (of flushing >> the buffer to disk.) >> >> You can also set immediateFlush to true to achieve this, but this will write >> to disk on _every_ event *in your application thread*. >> >> If performance is important, async logging is 10-20 times faster than >> synchronous logging. The difference between the normal file appender and >> random access file is much smaller (random access file appender is only 1.3 >> - 2 times faster than file appender). >> >> :-) >> >> Sent from my iPhone >> >>> On 2016/02/03, at 21:01, Veit Guna <[email protected]> wrote: >>> >>> immediateFlush="true" seems to work - without adding async config options. >>> Adding the system property does also work, but needs disruptor.jar on >>> the classpath - as it seems. Otherwise a ClassNotFoundException occurs. >>> Although the documentation states, that the RandomAccessFile appenders do >>> _not_ need the disruptor.jar ;). >>> >>> Ok then. Since I don't want to add an additional dependency, I would go for >>> immediateFlush="true". But now I'm wondering whether it would be better to >>> just use the normal RollingFileAppender with not specifying flush behavior >>> at all. Which one is faster in synchronous mode :)? >>> >>> Thanks >>> Veit >>> >>> >>> >>> Gesendet: Mittwoch, 03. Februar 2016 um 12:37 Uhr >>> Von: "Veit Guna" <[email protected]> >>> An: [email protected] >>> Betreff: Aw: Re: RollingRandomAccessFile and emtpy log file >>> Hi Remko. >>> >>> I've read about the AsyncLoggerContextSelector but I didn't try it - to be >>> honest. As the documentation doesn't state anything about >>> that the RollingRandomAccessFile appender needs async functionality, I >>> didn't took this into account. >>> Maybe there could be added some hint in the documentation about that (needs >>> async or not)? Or maybe just don't allow starting up log4j when >>> the configuration is (obviously) wrong :)? >>> >>> So I'll check for the async configuration option and report back. >>> >>> Thanks! >>> Veit >>> >>> >>> >>> >>> Gesendet: Mittwoch, 03. Februar 2016 um 12:13 Uhr >>> Von: "Remko Popma" <[email protected]> >>> An: "Log4J Users List" <[email protected]> >>> Betreff: Re: RollingRandomAccessFile and emtpy log file >>> I would say immediateFlush but that doesn't explain why you're not seeing >>> the update until after logging 600 KB when the buffer is only 256 KB... >>> >>> Have you tried setting system property >>> -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector >>> to switch on async loggers? This will ensure the buffer is always flushed >>> to disk, but it uses smart batching to achieve this in an efficient manner >>> (and it happens on the background thread, so no impact on your application). >>> >>> Sent from my iPhone >>> >>>> On 2016/02/03, at 17:47, Veit Guna <[email protected]> wrote: >>>> >>>> Hi. >>>> >>>> I'm using log4j 2.5 with the RollingRandomAccessFile. When the application >>>> starts up and performs logging, the logfile >>>> gets created, but nothing is written to it. Only after I stop the >>>> application the content appears. I also doublechecked the 256KB >>>> buffer. But logging 600KB doesn't seem to trigger a write to the file. >>>> Console appender is working fine. >>>> >>>> Any idea what I'm missing? >>>> >>>> Here's my configuration: >>>> >>>> --cut here-- >>>> <?xml version="1.0" encoding="UTF-8"?> >>>> <Configuration> >>>> >>>> <Properties> >>>> <Property name="logsPath">${sys:app.logs:-${env:APP_LOGS:-logs}}</Property> >>>> </Properties> >>>> >>>> <Appenders> >>>> <RollingRandomAccessFile name="rollingFileAppender" >>>> fileName="${logsPath}/app.log" >>>> filePattern="${logsPath}/app-%d{yyyy-MM-dd}-%i.log" immediateFlush="false"> >>>> <PatternLayout> >>>> <pattern>%d %-5p [%mdc{RQID}] [%c{1}] - %m%n</pattern> >>>> </PatternLayout> >>>> <Policies> >>>> <SizeBasedTriggeringPolicy size="10 MB" /> >>>> </Policies> >>>> <DefaultRolloverStrategy max="5" /> >>>> </RollingRandomAccessFile> >>>> <Console name="consoleAppender" target="SYSTEM_OUT"> >>>> <PatternLayout pattern="%d{HH:mm:ss,SSS} %-5p [%mdc{RQID}] [%c{1}] - %m%n" >>>> /> >>>> </Console> >>>> </Appenders> >>>> >>>> <Loggers> >>>> <Logger name="com.acme.app" level="info" /> >>>> >>>> <!-- spring --> >>>> <Logger name="org.springframework.security" level="info" /> >>>> <Logger name="org.springframework.transaction" level="info" /> >>>> <Logger name="org.springframework.orm.jpa" level="info" /> >>>> >>>> <!-- log SQL statements --> >>>> <Logger name="org.hibernate.SQL" level="error" /> >>>> <!-- log bind parameters --> >>>> <Logger name="org.hibernate.type" level="error" /> >>>> >>>> <Root level="info"> >>>> <AppenderRef ref="consoleAppender" /> >>>> <AppenderRef ref="rollingFileAppender" /> >>>> </Root> >>>> </Loggers> >>>> >>>> </Configuration> >>>> --cut here-- >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
