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]

Reply via email to