Re: Race condition with FileAppender.

I have been unable to reproduce the problem on Ubuntu Linux 6.06-1  
and gcc 4.0.3 running under VMWare Fusion on Mac OS/X either in  
single processor or double processor mode.  That is the glorious  
thing about race conditions, the slightly little change might hide  
them.  Thanks for the output when you were seeing corruption, it at  
least suggests that the problem isn't in the layout since all the  
bogus characters appear between perfectly formatted messages.  That  
suggests that the problem is in the FileAppender or probably more  
likely in the CharsetEncoder or CharsetDecoder.

I won't be able to work on it until Monday, however it would be  
helpful to know if setting LOG4CXX_LOCALE_ENCODING_UTF8=1 (which will  
replace the APR encoders/decoders with straight byte copies) or the  
equivalent manual hack to src/charsetencoder.cpp and src/ 
charsetdecoder.cpp changes the behavior.

I've also run the helgrind tool from valgrind 2.2.0 and generated a  
report of possible race conditions in the executed code, but I  
haven't had time to review them yet.

RE: Race condition with FileAppender.

On Saturday, June 30, 2007 7:27 AM, Curt Arnold wrote:
>
> LOGCXX-129 only reported problems with AsyncAppender which 
> was badly flawed in log4j 1.2.13 and earlier and deadlock 
> reports in log4j started getting more frequent.  The log4cxx 
> AsyncAppender was pretty much a straight port of the early 
> log4j equivalent and would be  
> expected to have the same problems under stress.   The new log4j  
> AsyncAppender should be ported over to log4cxx and that is 
> one of the remaining issues on a push to release.

Please note that with the current HEAD version, it is impossible to
configure log4cxx to use AsyncAppender.  Any appender that is attached
to an AsyncAppender results in the following error message:

    No appender named [<name>] could be found.

For details, see my earlier posting:
http://marc.info/?l=log4cxx-user&m=118244780603300&w=2

Moshe

Re: Race condition with FileAppender.

Hmm., that's really odd.  I can reproduce it on my two boxes with pent4
with hyperthreading enabled, but I can't on my weenie single lapetop cpu.

I'll try this and get back to you.

LOG4CXX_LOCALE_ENCODING_UTF8=1

Thanks,

Pete

On Sun, Jul 01, 2007 at 01:34:22AM -0500, Curt Arnold wrote:
> I have been unable to reproduce the problem on Ubuntu Linux 6.06-1  
> and gcc 4.0.3 running under VMWare Fusion on Mac OS/X either in  
> single processor or double processor mode.  That is the glorious  
> thing about race conditions, the slightly little change might hide  
> them.  Thanks for the output when you were seeing corruption, it at  
> least suggests that the problem isn't in the layout since all the  
> bogus characters appear between perfectly formatted messages.  That  
> suggests that the problem is in the FileAppender or probably more  
> likely in the CharsetEncoder or CharsetDecoder.
> 
> I won't be able to work on it until Monday, however it would be  
> helpful to know if setting LOG4CXX_LOCALE_ENCODING_UTF8=1 (which will  
> replace the APR encoders/decoders with straight byte copies) or the  
> equivalent manual hack to src/charsetencoder.cpp and src/ 
> charsetdecoder.cpp changes the behavior.
> 
> I've also run the helgrind tool from valgrind 2.2.0 and generated a  
> report of possible race conditions in the executed code, but I  

Re: Race condition with FileAppender.

On Sun, Jul 01, 2007 at 03:49:44AM -0700, pete <at> mu.org wrote:
> Hmm., that's really odd.  I can reproduce it on my two boxes with pent4
> with hyperthreading enabled, but I can't on my weenie single lapetop cpu.

I forgot to mention, that if I disable hyperthreading in the bios, then
the problem goes away.  I don't know if that helps, but there you go.

Pete

> 
> I'll try this and get back to you.
> 
> LOG4CXX_LOCALE_ENCODING_UTF8=1
> 
> Thanks,
> 
> Pete
> 
> On Sun, Jul 01, 2007 at 01:34:22AM -0500, Curt Arnold wrote:
> > I have been unable to reproduce the problem on Ubuntu Linux 6.06-1  
> > and gcc 4.0.3 running under VMWare Fusion on Mac OS/X either in  
> > single processor or double processor mode.  That is the glorious  
> > thing about race conditions, the slightly little change might hide  
> > them.  Thanks for the output when you were seeing corruption, it at  
> > least suggests that the problem isn't in the layout since all the  
> > bogus characters appear between perfectly formatted messages.  That  
> > suggests that the problem is in the FileAppender or probably more  
> > likely in the CharsetEncoder or CharsetDecoder.
> > 
> > I won't be able to work on it until Monday, however it would be  

Re: Race Condition with FileAppender.

I've created bug LOGCXX-186 (https://issues.apache.org/jira/browse/ 
LOGCXX-186) for this issue including much of the recent thread on  
log4cxx-user.  Further discussion and work should occur either within  
the bug report or on log4cxx-dev.

Unable to run executable built with MSVC 8.0

RE: Unable to run executable built with MSVC 8.0

Moshe Matitya wrote:
> I built a app using log4cxx with MSVC 8.0, and when I try to run it,
> it fails at startup, producing the following error message: 
> 
>     Unable To Locate Component
>     This application has failed to start because MSVCP80D.dll was not
>     found. Re-installing the application may fix this problem.
> 

I suspect you need to bind the manifest (created by the VC8 linker) into
log4cxx.dll
Something like this:-

mt.exe -nologo -manifest log4cxx.dll.manifest -outputresource:log4cxx.dll;2

MSVCP80D.dll on XP SP2 will go into the WinSxS directory, and the manifest
information
is needed to tell the loader where the DLL is.
If the .EXE already loaded MSVCP80D then you can get away without the
manifest.

HTH,
Roger.

RE: Unable to run executable built with MSVC 8.0

Isn't this something that should be done by ant when building log4cxx?

Thanks,

Moshe

________________________________

From: Roger Orr [mailto:rogero <at> howzatt.demon.co.uk]
Sent: Thu 7/5/2007 12:01 AM
To: 'Log4CXX User'
Subject: RE: Unable to run executable built with MSVC 8.0

Moshe Matitya wrote:
> I built a app using log4cxx with MSVC 8.0, and when I try to run it,
> it fails at startup, producing the following error message:
>
>     Unable To Locate Component
>     This application has failed to start because MSVCP80D.dll was not
>     found. Re-installing the application may fix this problem.
>

I suspect you need to bind the manifest (created by the VC8 linker) into
log4cxx.dll
Something like this:-

mt.exe -nologo -manifest log4cxx.dll.manifest -outputresource:log4cxx.dll;2

MSVCP80D.dll on XP SP2 will go into the WinSxS directory, and the manifest
information
is needed to tell the loader where the DLL is.
If the .EXE already loaded MSVCP80D then you can get away without the
manifest.

HTH,
Roger.

New information on next release?

Hello!

I have just joined the list, and I beg your forgiveness if I'm posting this 
question on the wrong list (please redirect me if I am).  I know this is a 
tired question, but I'm wondering if a new release can be expected in the 
near future. I looked through the archive, and I see that folks looked 
optimistic that there'd be a release in March.... but now that we're in July 
I thought I'd pose the question again.

I appreciate your help,

Andrew

_________________________________________________________________
Local listings, incredible imagery, and driving directions - all in one 
place! http://maps.live.com/?wip=69&FORM=MGAC01

Is log4cxx "easily" extensible?

Hello,

I'm a new poster, and I apologize if this e-mail is off-topic in any way.  I 
tried searching online for reviews that would give me insight about this 
question, but didn't find much.  I appreciate your help!

I am an intern who has been put in charge of designing a new logger for my 
company, and log4cxx looks great.  Unfortunately, it doesn't meet all of our 
(very specific) needs so we would have to extend it.  I'm hoping to get 
feedback from users who have tried to extend it. Was the code documented 
sufficiently well? (I've found great use documentation, but had trouble 
finding any design documentation that would help developers... this is 
probably my fault, so if I'm just looking in the wrong place let me know :)

On a related note, can anyone comment on the reliability of this library? My 
bosses won't commit to anything they don't believe is rock-solid, so if you 
think it is (or you don't) please let me know.

I really appreciate your help!  Re-using this code would really save me some 
time :)

-Andrew

_________________________________________________________________
http://im.live.com/messenger/im/home/?source=hmtextlinkjuly07