Hi Thorbjørn,
Thanks for the response.
I am not sure my problem is related to this buffering. I had considered that, but I don't get my logging even when my program is finished.
If I use System.out then my logging is fine. It is only when I use log4j or the Trace class that I start having issues.
In the java class I am using I setup a daemon thread in my constructor which runs in the background continually monitoring a connection I have to another server. When this starts the logging is fine.
However my problem occurs when I then send messages to same object which in effect is happening in a separate thread, however in the same job and JVM. At this point I get no further logging from either thread.
Kind regards
Luke
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Thorbjoern Ravn Andersen
Sent: 05 March 2011 13:29
To: Java Programming on and around the IBM i
Subject: 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,
midrange.com
