Hi Bruno,
Log4j is designed not to interrupt main application.
Per you two specific questions, the answer is the same, Log4j would just
print a error to System.err, and die itself. You can review source file
to verify that, it just catch IOException, and print error, retry may
occur. e.g. in SocketAppender.java:
---------------------
public void append(LoggingEvent event) {
if(event == null)
return;
if(address==null) {
errorHandler.error("No remote host is set for SocketAppender named
\""+
this.name+"\".");
return;
}
if(oos != null) {
try {
if(locationInfo) {
event.getLocationInformation();
}
oos.writeObject(event);
//LogLog.debug("=========Flushing.");
oos.flush();
if(++counter >= RESET_FREQUENCY) {
counter = 0;
// Failing to reset the object output stream every now and
// then creates a serious memory leak.
//System.err.println("Doing oos.reset()");
oos.reset();
}
} catch(IOException e) {
oos = null;
LogLog.warn("Detected problem with connection: "+e);
if(reconnectionDelay > 0) {
fireConnector();
}
}
}
}
-------------------------
Best wishes,
Dong
-----Original Message-----
From: Bruno Melloni [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2008 7:11 AM
To: Log4J Users List
Subject: How does log4j fail?
We have an application that does massive logging (about 100GB per day),
and log4j works like a charm. We manage disk allocation to the log
filesystem fairly well, but nobody is perfect. Since the application is
mission critical, we want to be 100% sure that logging failures won't
stop it.
So the question is:
When log4j is unable to log, how does it fail? Does it just stop
logging? (which would be OK) Or does it crash/hang the application?
We'd be very interested in finding the answer for at least two
scenarios:
1) Using a file-based appender and running out of disk space.
Having the appender (yes, it is custom) check for free space is not a
good option since the app is running on jdk 1.5. Migrating to jdk 1.6
is no viable at this time, and constantly spawning a Solaris 'df -k
<logPath>' is not very desirable.
2) Delegating logging to a separate box dedicated to logging, and use
something like a SocketAppender or other distributed mechanism. In such
a scenario we could loose the box, network, etc... So the focus would be
on how would the Appender would die/stop-logging. This would probably
be easier to custom-code if necessary.
Thanks,
bruno
---------------------------------------------------------------------
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]
