db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.
Date Sun, 22 Jan 2006 17:24:06 GMT
     [ http://issues.apache.org/jira/browse/DERBY-125?page=all ]

Bryan Pendleton updated DERBY-125:

    Attachment: svn_jan_22_2006.diff

Attached is the latest patch proposal, updated to the latest trunk,with all conflicts resolved
and derbyall passing. There are two changes in this patch proposal relative to the previous
 - I've changed the regression test to use the new test devised by Army. I've verified that
the test fails before the patch to DDMWriter, and succeeds after it. Although I agree that
the test is a bit delicate, it is much better to have a test which clearly demonstrates the
 - I've improved the comments in finalizeDssLength() a bit to explain my changes a bit better,
and also included a pointer to this bug report for those future historians who desire to study
the bug in more detail.

Kathey, Dyre, Army: thank you very much for your feedback on the previous proposals and on
the questions I raised. My preference is to treat your suggestions independently, and to open
separate JIRA entries to track resolving these questions in the future:
 - Improving DDMWriter traces to make them easier to read in the presence of continuations
and chaining
 - Modifying the client to process the length portion of DSS Continuation Headers, compatibly
with previous releases
 - Under SanityManager control, pre-filling the DDMWriter buffer with special non-zero data
to reveal memory corruption problems more readily
 - Investigating performance issues in large object handling with respect to both memory usage
and number of data copies

Thanks again to everybody who has helped me with the investigations into this bug.

> Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.
> -----------------------------------------------------------------------------------
>          Key: DERBY-125
>          URL: http://issues.apache.org/jira/browse/DERBY-125
>      Project: Derby
>         Type: Bug
>   Components: Network Server
>     Reporter: A B
>     Assignee: Bryan Pendleton
>  Attachments: changes.html, offByOne.jar, repro.java, svn_jan_12_2006.status, svn_jan_22_2006.diff
> DRDA protocol, which is the protocol used by Derby Network Server, dictates that all
DSS objects "with data greater than 32,763 bytes" should be broken down into multiple "continuation"
> When Network Server receives a "prepareStatement" call that has a very large number of
parameters, it can end up sending a reply DSS that is greater than 32K long to the client;
doing so breaks DRDA protocol.
> Note that this reproduction does NOT cause a protocol exception against the JCC driver--without
further investigation, it would appear JCC doesn't mind that the DSS is too long.  However,
other DRDA clients (such as the DB2 ODBC client) will see that the data is too long and will
fail because of it.
> To reproduce, one can create a simple table and then prepare a statement such as:
> SELECT id FROM t1 WHERE id in ( ?, ?, [ ... lots and lots of param markers ... ], ?)
> Note that JCC uses deferred prepare by default; when connecting, one must append the
"deferPrepares=false" attribute to the end of the URL in order to reproduce the problem (that
or just try to execute the statement, since preparation will be done at execution time). 
When doing the prepare, I added a line in the "flush" method of org.apache.derby.impl.drda.DDMWriter.java
to see how large the reply DSS was, and for cases where the number of parameter markers was
high, the number of bytes in the single DSS would surpass 32K, and thus break protocol.
> Network Server correctly uses continuation DSSes for LOBs and for result set data (data
returned as the result of a query) that is greater than 32K.  The problem appears to be in
"other" cases, such as for the prepareStatement call described above.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message