[ http://issues.apache.org/jira/browse/DERBY-125?page=all ]
Bryan Pendleton updated DERBY-125:
----------------------------------
Attachment: changes.html
svn_jan_12_2006.diff
svn_jan_12_2006.status
Attached is a focused patch which addresses *only* the problems in
DDMWriter.finalizeDSSLength(). The patch includes a test, and updates to the
master output files. Note, unfortunately, that this test works even *without*
the changes to DDMWriter.java. The reason for this is explained in the
changes.html file. I would like to write a better test, but don't know how to.
Reviewers, please look at this patch and see if you can suggest a better way to
write the test. Even if we can't write a better test, I think we should still
review and consider this patch, because it fixes an important bug (and it is a
pre-requisite for the fixes to DERBY-491 and DERBY-492, which also have tests,
so it will get additional testing there.)
> 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, repro.java, svn_jan_12_2006.diff,
> svn_jan_12_2006.status
>
> BACKGROUND:
> 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" DSSes.
> PROBLEM:
> 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.
> REPRODUCTION:
> 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.
> NOTES:
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
