Peter -

To add to your comments:

In our systems (real-time call processing engines for carrier 
networks).... a s/w fault is many orders of magnitude worse than no logs 
being available.  One thing that happens in our customer environments is 
that when something goes wrong... the IT/sysadmin folks will look at 
syslog entries -- and if the appender or logger framework were to log 
something they'd see it.  The more 'process' oriented companies will have 
their NOC's review the logs and trap major issues as soon as they happen.

Renny Koshy

"Peter Steele" <[EMAIL PROTECTED]> 
09/23/2008 01:26 PM
Please respond to
"Log4CXX User" <>

"Log4CXX User" <>

RE: File system full causes log4cxx to crash

I’ll add my own agreement to this. It’s not acceptable for a logger to 
crash an application when the volume becomes full. My solution to use a 
try/catch works for us for now since we only have a single appender, but 
as was mentioned below if we decided to add a second appender the 
try/catch is a very big hammer, potentially preventing the other appender 
from running. Still, it’s better than the application crashing on us.

Sent: Tuesday, September 23, 2008 10:20 AM
To: Log4CXX User
Subject: Re: File system full causes log4cxx to crash

I agree wholeheartedly.... 
If it gets into something like the scenario mentioned below, maybe the 
logger can put a syslog entry, or console/stderr output (as configured by 
the user in some global setting)? 

Renny Koshy

09/23/2008 01:12 PM 

Please respond to
"Log4CXX User" <>

"Log4CXX User" <> 

Re: File system full causes log4cxx to crash

"Jacob L. Anawalt" <[EMAIL PROTECTED]> writes:
> I am glad it worked out for you. At the same time I am concerned that
> you had to do this and I didn't. I would like to reproduce the problem
> so that I can handle it, preferably without putting try/catch around
> every logging statement...

Some time back, I sent a message to the list asking what the behavior
of an appender that throws an exception should be.  As it is, a stray
exception can unwind all the way through the library into the calling 

To my mind, wrapping log invocations with try/catch blocks isn't a
completely satisfactory solution, as if you have multiple appenders
associated with a logger, the exception will prevent subsequent
appenders from being invoked.

Personally, I think log4cxx should provide a guarantee that a log
invocation will not throw an exception under any circumstances.  One
of the common use cases for emitting a log event is when you're in a
error handling path, the last thing you want to worry about is the 
logging framework making hash of things.

Two alternatives that come to mind are that every appender's append()
method needs to have a try/catch block to squelch any exceptions, or
that the appendLoopOnAppenders should have a try/catch block around
each call to doAppend() invocation.  Or since all it takes is one bad
appender (and even if all appenders that are distributed with log4cxx
are fixed, there's no guarantee that user's appenders will also be), a
hybrid of the two approaches where the try/catch block around
doAppend() logs an internal message about the unhandled exception.

Basically, a framework shouldn't allow a callback to subvert or
compromise the function of the framework itself.


J.T. Conklin

Reply via email to