[jira] Commented: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.

["Bryan Pendleton (JIRA)" <de...@db.apache.org>]

    [ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12360519 ] 

Bryan Pendleton commented on DERBY-170:
---------------------------------------

(This comment refers *just* to DERBY-170. DERBY-491 and DERBY-492 are completely different problems and I'll have more to say about them later.)

The basis of the DERBY-170 problem is the method DDMReader.skipDss; this method does not properly handle large DDM Objects which are written using continued DSS data structures.

The way that the bug gets to this point is as follows:
1) The client sends a PRPSQLSTT to prepare the insert statement
2) The prepare fails because the table doesn't exist; the server correctly sends back an error message.
3) The client has already moved on to sending the DSCSQLSTT request. The server reads this, notices that the prepare failed, and skips through the request.
4) The client has already moved on to sending the EXCSQLSTT request. The server reads this, notices that the prepare failed, and calls skipRemainder to skip through the request.

This is where the problem occurs. The client has included the enormous character string as the parameter to the EXCSQLSTT; this parameter string is so long that it is continued through multiple 32K blocks. However, the skipRemainder method can't handle continued objects properly. What it does is to read the first block, note that it is a continued object, and then calls skipDSS to skip it. But skipDSS only skips the first 32K segment of the giant parameter; it doesn't skip the continued object segments. So the skipRemainder() method terminates without having digested the entire parameter object, and control pops out to the main processCommands loop, which then reads the  next parameter object segment, tries to interpret it as a new DSS, and rejects it with an assert.

Here is the diff that I am currently experimenting with; so far, results have been promising. Please let me know your opinions on my analysis of the problem so far.

Index: DDMReader.java^M
===================================================================^M
--- DDMReader.java  (revision 357039)^M
+++ DDMReader.java  (working copy)^M
@@ -1348,6 +1348,11 @@^M
     */
    protected void skipDss() throws DRDAProtocolException
    {
+       while (dssIsContinued)
+       {
+           skipBytes((int)dssLength);
+           readDSSContinuationHeader();
+       }
        skipBytes((int)dssLength);
        topDdmCollectionStack = EMPTY_STACK;
        ddmScalarLen = 0;



> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-170
>          URL: http://issues.apache.org/jira/browse/DERBY-170
>      Project: Derby
>         Type: Bug
>   Components: Network Server
>  Environment: Derby Network Server running with either JDBC or ODBC driver.
>     Reporter: A B
>     Assignee: Bryan Pendleton
>  Attachments: assert_repro.java, storedProcs.java, stored_proc_repro.java
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client).  I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure.  Note that the problem does NOT happen if the target table actually exists.  Repro can be found in the "assert_repro.java" file attached to this bug.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira