RE: File system full causes log4cxx to crash
With 0.9.7 your app threw and exception and aborted when the log volume filled up. Putting a try/catch around the log call prevented the crash. I put the same try/catch in my wrapper functions and that worked as well, so that's all there was to it. I like simple solutions. Thanks for pointing me in the right direction. -Original Message- From: Peter Steele [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 5:46 PM To: Log4CXX User Subject: RE: File system full causes log4cxx to crash Okay, thanks, I'll give it a try. -Original Message- From: Jacob L. Anawalt [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 4:24 PM To: Log4CXX User Subject: Re: File system full causes log4cxx to crash On 2008-09-22 17:03, Peter Steele wrote: We're using 0.9.7 in fact, under FreeBSD. Our case is bit more Maybe we need to catch this IOException in our wrapper functions? The IOException was in the 0.10.x code. I didn't see any exception around the writing to files in 0.9.7. As near as I could tell the iostream library was handing the full filesytem error by not writing any more but the rest of the program and logging kept working. Perhaps it is something with the C wrappers. You could try my test program with a small file based filesystem loop mounted at /mnt -- Jacob Anawalt Gecko Software, Inc. [EMAIL PROTECTED] 435-752-8026
Re: XMLSocketAppender: Reconnection fails
I reported it back in May: http://issues.apache.org/jira/browse/LOGCXX-277
It is a bug in 0.10.0, but is fixed in subversion. The fix is to make that
if( !thread.isActive() )
On Tue, Sep 23, 2008 at 9:56 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi All,
for some reason, a XMLSocketAppender does not reconnect to
Chainsaw, after some initial events have been sent and then
chainsaw was killed.
What I have figured out is that in the following code snippet
from SocketAppenderSkeleton.cpp
-- schnipp --
void SocketAppenderSkeleton::fireConnector()
{
synchronized sync(mutex);
if (thread.isActive()) {
thread.run(monitor, this);
}
}
schnapp
the method thread.isActive always returns false. It seems that
the methods returns true if there is some (apr) thread object
instantiated. But that does not happen.
The same behaviour is shown when the connection cannot be established
at the beginning of a session.
Is that a known bug/feature?? I'am using log4cxx 0.10.0.
Cheers
Stefan
--
Dale King
Re: XMLSocketAppender: Reconnection fails
Hi Dale,
thanks a lot. I haven't expected such a bug in a
release. Better switch to the latest head revision
then ..
Stefan
-Original Message-
Date: Tue, 23 Sep 2008 17:04:52 +0200
Subject: Re: XMLSocketAppender: Reconnection fails
From: Dale King [EMAIL PROTECTED]
To: Log4CXX User log4cxx-user@logging.apache.org,
[EMAIL PROTECTED] [EMAIL PROTECTED]
I reported it back in May:
http://issues.apache.org/jira/browse/LOGCXX-277 [1]
It is a bug in 0.10.0, but is fixed in subversion. The fix is to make
that if( !thread.isActive() )
On Tue, Sep 23, 2008 at 9:56 AM, [EMAIL PROTECTED] [2]
wrote:
Hi All,
for some reason, a XMLSocketAppender does not reconnect to
Chainsaw, after some initial events have been sent and then
chainsaw was killed.
What I have figured out is that in the following code snippet
from SocketAppenderSkeleton.cpp
-- schnipp --
void SocketAppenderSkeleton::fireConnector()
{
synchronized sync(mutex);
if (thread.isActive()) {
thread.run(monitor, this);
}
}
schnapp
the method thread.isActive always returns false. It seems that
the methods returns true if there is some (apr) thread object
instantiated. But that does not happen.
The same behaviour is shown when the connection cannot be
established
at the beginning of a session.
Is that a known bug/feature?? I#39;am using log4cxx 0.10.0. [4]
Cheers
Stefan
--
Dale King
Links:
--
[1] http://issues.apache.org/jira/browse/LOGCXX-277
[2] mailto:[EMAIL PROTECTED]
[3] mailto:[EMAIL PROTECTED]
[4] http://0.10.0.
log4cxxl compile fails
Compiling log4cxx in Microsoft Visual Studio 6.0 fails and the first error is below. SQLLEN is not defined anywhere. What am I doing wrong? Thanks! C:\apr-util\dbd\apr_dbd_odbc.c(134) : error C2061: syntax error : identifier 'SQLLEN' - Don Winans Software Engineer NORTHROP GRUMMAN Mission Systems Defense Mission Systems Communication and Information Systems Division 9326 Spectrum Center Blvd. San Diego, CA 92123 858-514-9687 [EMAIL PROTECTED]
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 code. 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. --jtc -- J.T. Conklin
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 [EMAIL PROTECTED] (J.T. Conklin) 09/23/2008 01:12 PM Please respond to Log4CXX User log4cxx-user@logging.apache.org To Log4CXX User log4cxx-user@logging.apache.org cc Subject 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 code. 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. --jtc -- J.T. Conklin
RE: File system full causes log4cxx to crash
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@logging.apache.org To Log4CXX User log4cxx-user@logging.apache.org cc Subject 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. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] (J.T. Conklin) 09/23/2008 01:12 PM Please respond to Log4CXX User log4cxx-user@logging.apache.org To Log4CXX User log4cxx-user@logging.apache.org cc Subject 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 code. 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. --jtc -- J.T. Conklin
