Isn't it up to the Framework and OS to some degree to decide when buffering occurs? You might be able to flush sooner by digging down into the Layout / Converter level. If the log messages are very long perhaps you could do some optimization to flush after every X bytes instead waiting until the StringBuffer containing the entire line is passed to Write. Might slow down writing a bit though.
Somewhat related articles: http://blogs.msdn.com/b/brada/archive/2004/04/15/114329.aspx http://stackoverflow.com/questions/1862982/c-sharp-filestream-optimal-buffer-size-for-writing-large-files ________________________________ From: Stefan Bodewig <bode...@apache.org> To: Log4NET User <log4net-user@logging.apache.org> Sent: Tuesday, October 25, 2011 11:27 AM Subject: Re: Turning off buffered IO for the RollingFileAppenders On 2011-10-24, Cook, Henri wrote: > I’m a recent convert to the Log4Net way and I’ve implemented myself a > RollingFileAppender as below – what I can’t seem to do is stop it > buffering! I’m trying to debug a live transfer process using log > entries and having it batch 20-30 log entries before writing them to > file is a bit limiting. This really is difficult as I must admit I've never seen any buffering occur myself. I've often "tail -f"ed logfiles and they have always been live. Looking trough the code there is a whole lot of indirection going on. The FileStream is wrapped in a LockingStream which in turn is wrapped in a StreamWriter which finally ends up wrapped by a CountingQuietTextWriter. It looks as if all of those indirections are passing on Flush() correctly and by default the stream will be flushed after each logging event. Can the delay you observe be caused by something else sitting in-between? Since your log resides on C:\ this shouldn't be a network share where the system may add extra buffering. A virus scanner, maybe? Stefan
