[
http://issues.apache.org/jira/browse/DERBY-125?page=comments#action_12362895 ]
Kathey Marsden commented on DERBY-125:
--------------------------------------
Hi Bryan
Thank you so much again for your excellent documentation. I am learning quite
a bit and appreciate your very high standards for your work #:) I think once
the series of continuation fixes is committed we should update the
DssProtocolErrors page that Army wrote to point to your documents. I don't
know if they should move to the documents to Wiki or if it is ok to just keep
them here and point to the bugs.
My only comment on the code change are:
1) Can you submit a new patch after updating your client for the DERBY-170
commit.
2) Can you add some brief comments to the code containing
- a reference to DERBY-125 and the changes.html here
- just a couple brief comments in the code as to why we have to add 1 to
startOfCopyData and the continuation flag hnadling changes that you made.
With regard to your questions and notes
On the reading of DDMWriter traces
I tend to find the client tracing more helpful than the server-side tracing ,
and shows the JDBC calls to provide better context. That said, probably the
problems you note exist on the client side too, so it might be good to file
enhancements while you are thinking about it.
On prefilling the buffer with a known value to try to flush out corruption in
the sent data:
I think this is not a bad idea if (SanityManager.DEBUG), but not a high
priority.
Why don't bad DSS continuation headers cause more symptoms?
You mentioned that this might be because the Derby client is very liberal in
assuming that the block length is 32767 if the continuation bit is set. I
think that it would be worthwhile for the client to be changed to not make this
assumption when talking to 10.2 or higher servers. It would help prevent
regressions in this area that might be very difficult to reproduce.
Should there be a limit to DDMWriter auto-expansion?
One poorly formed idea is to eliminate the expansion all together by istead of
expanding have a pool of buffers available to all the DDMWriters. If a
DDMWriter needs to write more, it picks up a new buffer and returns it to the
pool when no longer needed. It seems like there should be a way to eliminate
the shifting all together as well or at least shift sooner after the overrun
happens to avoid shifting large amounts of data.
> 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
