Re: log4j/Trace class Threading and STDOUT

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,