RE: Loggers and threading

["Moul, Russell G" <ru...@boeing.com>]

 
I finally got back to this.  This work around worked for me, thanks.

In addition to making mods to allow configure to set
LOG4CXX_LOCALE_ENCODING_UTF8, it appears that charsetencoding.cpp needs
to include log4cxx_private.h, so it can see this define.

Russ

-----Original Message-----
From: Curt Arnold [mailto:carnold@houston.rr.com] 
Sent: Saturday, June 25, 2005 9:18 PM
To: Log4CXX User
Subject: Re: Loggers and threading


On Jun 24, 2005, at 5:53 PM, Moul, Russell G wrote:

> I'm encountering problems using multiple threads that log to the same 
> logger.  The following is a simple test I put together to issolate the

> problem and a backtrace from the failure.  Any suggestions would be 
> welcome.
>

Thanks for the report.  I don't have time to research it at the moment,
but I wanted to share my thoughts from just looking at the stack trace.
If someone else wants to dig deeper, please feel free.

Any chance that your implementation of standard template library is not
reentrant?  The call itself looks like something going wrong on a call
to STL on a resource on the stack.  Maybe things got dorked somewhere
else, but it looks really clean for some type of overwrite or collision
on a shared resource.

The back trace appears to be in the char* to wchar_t* decoder
implemented using apr_xlate.  If you just need a work-around, one of the
other decoder/encoder combinations might not suffer from the same issue
(or it may be totally unrelated to the encoding and something else
entirely).  If you know that your locale encoding is UTF-8, you can
bypass all the encoding/decoding hassle by specifying the preprocessor
macro LOG4CXX_LOCALE_IS_UTF8=1 (unfortunately neither of the builds has
an option to specify that at this time) and
LOG4CXX_LOGCHAR_IS_UTF8=1 (I think -Dlogchar=utf-8 on the Ant build)
which is cause the "trivial" decoder/encoder pair to be used for
conversion from the locale's char* to the internal character
representation.