[ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12362734 ]
Bryan Pendleton commented on DERBY-170: --------------------------------------- Hi Kathey, I looked at Reply.ensureBLayerDataInBuffer, and I believe that it does *not* have the same problem. The issue in DDMReader.java on the server side is that its implementation of ensureBLayerDataInBuffer, in the "is continued" case, was not calling ensureALayerDataInBuffer. The implementation on the client side is slightly different, and it always calls ensureALayerDataInBuffer, in both the "is continued" case and in the non-continued case. So I believe that the client code is correct with respect to this problem. While stepping through the Reply.java code, I did see a few things that worried me: - the comment which accompanies Reply.compressBLayerData seems almost totally wrong to me and I fear it could substantially mislead future readers of the code - the implementation of Reply.compressBLayerData uses an inline for() loop to shift the bytes around, rather than calling System.arraycopy, which seems like it could be a performance problem. However, neither of these seemed serious enough to warrant including into this particular patch. Can you take another look at the client's Reply.java and let me know if you think I've misunderstood it? > 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, changes.html, storedProcs.java, > stored_proc_repro.java, svn_jan12_2006.diff, svn_jan12_2006.status > > 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
