(Disclaimer: I wouldn't recommend using log4j1.3 alpha in production, and this email describes a solution that relies on log4j 1.3's features).
Assuming it's ok to lose events (as would happen with a fileappender and no disk space), log4j 1.3 provides two new appenders (and matching receivers) that could meet your needs: MulticastAppender/MulticastReceiver UDPAppender/UDPReceiver Set up a new machine on the network to run log4j's SimpleSocketServer. Obviously, if you're using MulticastAppender, the target machine must be reachable via multicast from the source machine. If you're using UDPAppender, the target machine must be reachable via UDP from the source machine. SimpleSocketServer's log4j configuration file should contain any appender configuration you would like to use (file, db, etc), as well as the MulticastReceiver or UDPReceiver definition. Set up the server generating events to send events via MulticastAppender or UDPAppender. You may want to add a the Multicast/UDP appender to an AsyncAppender. Chainsaw V2 can also process events generated by MulticastAppender/UDPAppender. Hope this helps - I'm sure there are other ways to solve this problem - this one should avoid the issue of blocking. Scott -----Original Message----- From: Andreas Knecht [mailto:[EMAIL PROTECTED] Sent: Sun 3/6/2005 10:47 PM To: [email protected] Cc: Subject: RollingFileAppender when running out of disk-space Hello everyone, we have recently encountered a problem with log4j, when we run out of disk-space on one of our production servers. It causes slowdowns in the particular web application that we do the logging for. We have actually observed this happen live, and are quite sure that it is caused by log4j. Now the simple solution would obviously be to clean out old log files regularly, or setup a script to do this, to prevent the server from running out of disk space. Unfortunately we do not have access rights to these production boxes to do this, and there's a very large number of web applications deployed. The system administrators we go through don't have time to setup scripts for cleaning out old log files, or to clean out old log files manually. Currently I've been looking at several options to work around this: 1.) We could implement an AsyncAppender. However I don't believe that this will solve the slowdown issues, since the log4j documentation mentions that if the buffer fills up, the append() method will block. I'm guessing that this will happen if we run out of DiskSpace, and the attached FileAppender will get into problems. I've however not tried this in practice. 2.) Use a SocketAppender to log all the output to: a.) a different server. b.) locally, which should still have the effect of doing the logging asynchronously. The log4j documentation is somewhat ambiguous when it comes to describing the blocking behaviour of the SocketAppender. According to the documentation, 'if the remote server is down or unreachable, the logging events will simply be dropped.' Further down however it mentions: 'where the network link to the server is down, the client will eventually be blocked.' What we need is a solution that once we run out of disk-space on the server, will simply drop all logging statements until more disk-space is added without causing any slowdown in the application. Alternatively, we could consider setting up a server simply for logging purposes, however we do not want our web-app to slow down, if we can't reach this logging server for any reason either. Does anyone have suggestions as to how this can be achieved? Regards, Andreas --------------------------------------------------------------------- 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]
