That isn't the case. In so far as there aren't two instances of
DailyRollingFileAppender writing to the same location. That said the
application is multithreaded but that all should be synchronized.
On Jul 17, 2008, at 1:00 AM, Curt Arnold wrote:
On Jul 16, 2008, at 2:03 PM, Robert Nicholson wrote:
I'm noticying right now the following situation
-rw-r--r-- 1 311170 Jul 16 14:00 name.log
-rw-r--r-- 1 455880 Jul 16 14:00 name.log.2008-07-15
What you should see is that today's log is actively overwriting
yesterday's
rolled log.
So yesterdays log is history as it's been overwritten.
Can anybody explain this behaviour and whether a newer version
corrects this
problem?
Very common and expected behavior if you have two instances of
DailyRollingFileAppender writing to the same location on a Unix.
One instances renames the current file and creates a new file, when
the second instance attempts to roll, it cannot create the new file
and continues writing to the "old" file, but now renamed file. The
moral is not not allow two instances of DailyRollingFileAppender to
contend for the same file names.
---------------------------------------------------------------------
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]
