db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.
Date Mon, 16 Jan 2006 22:58:21 GMT
    [ 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

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
> 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