logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maarten Bosteels" <mbosteels....@gmail.com>
Subject Re: Problems with rollover of RollingFileAppender - data loss
Date Mon, 17 Nov 2008 10:05:24 GMT
what about using two processes:
* a long-lived process that receives all logging events via a SocketNode,
see [1] and writes them file via a FileAppender
* the short lived program that you already have, using a SocketAppender to
send events to the above process

[1]
http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/SimpleSocketServer.html

Maarten

On Sun, Nov 16, 2008 at 11:47 PM, <dhallammail-log4j@yahoo.com> wrote:

> Hi,
>
> I'm running log4j-1.2.15 and have a problem that I'd like to put forward to
> see if anyone has a solution.
>
> I have an application that is very short lived but is run many times.  It's
> invoked by an external scheduling and orchestration application that can
> only run the application by constructing a fresh JVM via JNI every time it
> wants to run it.  The application logs using log4j and its
> RollingFileAppender with append=true.
>
> The problem that I have encountered is that I have observed that sometimes
> the log files are getting partially wiped.  I am putting this down to the
> fact that the JVM might be shutting down whilst the rolling activity is
> taking place - resulting in partially rolled files.  I have tried adding a
> shutdown hook to invoke LogManager.shutdown() with the hope that this would
> block until the appenders had finished doing their work before the JVM
> shutdown but this doesn't appear to work.  I was able to replicate this by
> invoking the application many times continually. It doesn't happen often
> (maybe 1% with my setup) - I think the conditions have to be right, i.e.
> start rolling just before the app shuts down.
>
> Has anyone got any ideas, solutions or workarounds?
>
> Many thanks,
>
> Dave
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message