Re: log4j/Trace class Threading and STDOUT

[Thorbjoern Ravn Andersen <ravn@xxxxxxxxxx>]

Den 04/03/11 09.48, Klugman, Luke skrev:
> However my problem is with my logging. I have tried using both log4j and
> the ibm Trace class, but neither of them log to stdout correctly. As in
> effect I am running two threads from my program, I only get the stdout
> for the thread that starts first. As soon as I invoke a method on the
> class in a separate thread all my stdout ends.
>
> I am running this in batch mainly so am just looking at the STDOUT I get
> to QPRINT.
If I understand your question correctly you are asking why log messages 
you write in batch to System.out do not show in QPRINT.

Based on Classic JVM experience, I believe that there is a buffer in 
play here between the System.out stream and QPRINT which needs to fill 
up before being flushed so that QPRINT will always be a bit behind until 
the program exits resulting in the buffer being flushed.

This means that you cannot see the latest messages in QPRINT for a 
running program, which made it useless for diagnostic purposes for us.  
I believe you describe the same symptom.



We found that normal log-files work the best for us, and that our needs 
for configurability are slightly better catered to by the logback fork 
of log4j.

Basically we have two log folders pr application, one at INFO level 
which is always on, and one at DEBUG level which is turned on when 
forensic information is needed.  The launcher program sets current 
working directory to the location of these folders, making logging 
configuration simple.

In each folder a log file is created pr run of the program timestamped 
with the time of run (the timestamp log file name is to my knowledge not 
a part of log4j), so multiple concurrent runs have separate log files.  
Also old log files are removed on a regular basis.   Due to our 
infrastructure programs are restarted on a regular basis, so logfiles 
are on a manageable size.

Hope this saves you a day or two.

Best regards,