Oops! I'm Sorry.
Thanks,
Tomer
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Klugman, Luke
Sent: Monday, March 07, 2011 6:26 PM
To: Java Programming on and around the IBM i
Subject: RE: log4j/Trace class Threading and STDOUT
Hi Tomer,
I think this reply was meant for this thread "Locks are not released when executing SQL Select on AS400/DB2,using IBM Toolbox for Java (JDBC Driver)"
Kind regards
Luke
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Tomer Sason
Sent: 07 March 2011 16:09
To: Java Programming on and around the IBM i
Subject: RE: log4j/Trace class Threading and STDOUT
Hi there
Here a code example that you can run and showing the problem.
------------------- Start of Code --------------------
package db.testDB;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
public class DB2LockTester {
public static final String AS400_DB2_DRIVER_NAME = "com.ibm.as400.access.AS400JDBCDriver";
public static void main(String[] args) {
String dbUser = "myDbUser";
String dbPassword = "myPassword";
String dbURL = "jdbc:as400://172.11.22.222";
java.util.Properties prop = new java.util.Properties();
prop.put("user", dbUser);
prop.put("password", dbPassword);
prop.put("xa loosely coupled support", "0");
prop.put("transaction isolation", "read uncommited");
prop.put("cursor hold", "false");
prop.put("lazy close", "false");
prop.put("rollback cursor hold", "false");
prop.put("block criteria", 0);
prop.put("data compression", "false");
prop.put("extended dynamic", "false");
prop.put("prefetch", "false");
prop.put("hold input locators", "false");
prop.put("hold statements", "false");
try {
Class.forName(AS400_DB2_DRIVER_NAME);
// Get a connection
Connection connection = DriverManager.getConnection(dbURL, prop);
connection.setAutoCommit(true);
connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
connection.setHoldability(ResultSet.CLOSE_CURSORS_AT_COMMIT);
String sql = "SELECT * FROM AMS#LB.TOM_TST WHERE (SUG_REC = 2)";
// Execute SQL select
Statement stmnt = connection.createStatement();
ResultSet rs = stmnt.executeQuery(sql);
// ---> Here job QZDASOINIT was created
rs.next();
// Close the ResultSet/Statement
rs.close();
stmnt.close();
// ---> Here job QZDASOINIT was ended
// ---> Now - Do it again
stmnt = connection.createStatement();
rs = stmnt.executeQuery(sql);
// ---> Here job QZDASOINIT was created
rs.next();
// Close the ResultSet/Statement
rs.close();
stmnt.close();
// ---> Here job QZDASOINIT was NOT ended
// Close the connection
connection.close();
// ---> Here job QZDASOINIT was ended
} catch (SQLException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
------------------- End of Code --------------------
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Thorbj?rn Ravn Andersen
Sent: Monday, March 07, 2011 5:08 PM
To: 'Java Programming on and around the IBM i'
Subject: RE: log4j/Trace class Threading and STDOUT
Hi Luke.
It sounds like your scenario is a bit more complex than I thought.
Can you create a minimal example showing the behavior, and post the code?
/Thorbjørn
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Klugman, Luke
Sent: 7. marts 2011 10:15
To: Java Programming on and around the IBM i
Subject: RE: log4j/Trace class Threading and STDOUT
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
