Server hang when invalid string is bound to datetime columns.

• Key: DERBY-149
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Kathey Marsden
• Reporter: A B
• Component/s: Network Server
• Fix Version/s: 10.1.2.1, 10.2.1.6

Description

When running against Derby Network Server with the JCC driver, attempts to bind an invalid date/time string to a date/time/timestamp parameter lead to a hang in either the JCC client or in the Network Server (not sure which).

The problem does NOT occur if the same thing is run against a DB2 server, which suggests the bug is in Network Server, not in the JCC driver. That said, though, the problem also does NOT happen if one uses an ODBC client to connect to Network Server, instead of a JDBC client--so perhaps it's a problem with JCC, after all...hard to say one way or the other...

Here's a simple program to reproduce the problem:

import java.sql.*;

public class go {

public static void main (String[] args) throws Exception {

Class.forName("com.ibm.db2.jcc.DB2Driver");
Connection c = DriverManager.getConnection(
"jdbc:derby:net://localhost:1527/ugh;create=true", "bah", "humbug");

Statement s = c.createStatement();
try {
s.execute("drop table dt");
} catch (SQLException se) {}

s.execute("create table dt (d date)");
PreparedStatement pSt = c.prepareStatement("insert into dt values (?)");

try {
pSt.setString(1, "oops"); // invalid date value.
pSt.execute();
} catch (SQLException se) {
System.out.println("Got " + se.getSQLState() + ": " + se.getMessage());
}
}

}

Of course, in order for the program to run, one must start the Network Server on port 1527 first.

Comments

[A B]

The description originally said that the hang was in the "client program." I'm changing it to say that the hang is either in the JCC client or else in the Network Server, since that seems like a more accurate statement.

[Kathey Marsden]

Looking at this problem, I see that other types of errors, such as insert of a null value into a not null column seem to work ok. Looking at two types of errors in the trace, I see the following.

SUCCESSFUL ERROR PROCESSING (invalid insert of null value. handled ok)
[derby] SEND BUFFER: EXCSQLSTT
[derby] SEND BUFFER: SQLDTA
[derby] SEND BUFFER: RDBCMM
[derby] RECEIVE BUFFER: SQLCARD (With error 23502)
[derby] RECEIVE BUFFER: ENDUOWRM
[derby] RECEIVE BUFFER: SQLCARD (null SQLCARD)


PROBLEM ERROR PROCESSING (invalid conversion)

[derby] SEND BUFFER: EXCSQLSTT
[derby] SEND BUFFER: SQLDTA
[derby] SEND BUFFER: RDBCMM
[derby] RECEIVE BUFFER: SQLCARD (Exception 22007)

In the problem case, the server never sends the ENDUOWRM and SQLCARD that it should. The client blocks waiting for a response to its chained RDBCMM which the server never sent.

In the server, in parseSQLDTA on exception, we call skipRemainder(false) to skip the rest of the DSS. The false parameter means it will skip DSS's even if they have a different correlation id, which means in this case it gets a little too skippy and skips the RDBCMM Command.

Changing the line to skipRemainder(true) fixes the problem and makes sense to me because the DRDA manual seems to indicate that you should only get a new correlation identifier for a new command (page 76).

My specific question (at last) is this:

Are there any situations where we might need to skip a DSS with a different correlation ID when parsing the parameters in parseSQLDTA?

[A B]

I looked at the rest of the DRDAConnThread file and the only other places where "skipRemainder(false)" is called are 1) during connection authentication and 2) in cases where the client explicitly specified that severe errors should break the chain (in which case we call "errorInChain" and that method calls "skipRemainder(false)"). I can understand it's use in both of these cases--but like you say, Kathey, I don't really understand why we would be passing "false" to skipRemainder for the parseSQLDTA method.

I skimmed through what I thought were the relevant sections of the DRDA/DDM manuals and I saw nothing in them to indicate that we should be skipping DSSes with different correlation id's when parsing the parameters for SQLDTA causes an error. So if changing the "skipRemainder" call to pass "true" fixes the problem and all of our other tests pass, it seems like it's an acceptable fix to me...

(For what that's worth.)

[Kathey Marsden]

checked in fix to the trunk. Thanks Arm for looking at it so carefully.

Date: Mon Sep 26 12:39:26 2005
New Revision: 291721

URL: http://svn.apache.org/viewcvs?rev=291721&view=rev
Log:
DERBY-149
Fix Server hang when invalid string is bound to datetime columns.
Changes network server to skip only the current DSS and not all chained DSS's
when parsing parameter data in SQLDTA.

[Kathey Marsden]

Checked this issue into 10.1

Date: Mon Oct 10 20:46:53 2005
New Revision: 312801

URL: http://svn.apache.org/viewcvs?rev=312801&view=rev

[Kristian Waagan]

Verified the fix on 10.1.2.1 and trunk, and closed the issue.
Also tested that the test program indeed did hang on 10.0.2.1 and 10.1.1.0.

Output from test program on 10.1.2.1:
]$ java -classpath ./db2jcc.jar:./db2jcc_license_c.jar:../db-derby-10.1.2.1-lib/lib/derbyclient.jar:./ go
Got 22007: DB2 SQL error: SQLCODE: -1, SQLSTATE: 22007, SQLERRMC: 22007.S.181