[ 
http://issues.apache.org/jira/browse/DERBY-326?page=comments#action_12378200 ] 

Tomohito Nakayama commented on DERBY-326:
-----------------------------------------

I found difference in .out file of  SuicideOfStreaming in execution of derbyall,
after updated to repository .

********* Diff file 
derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/SuicideOfStreaming.diff
*** Start: SuicideOfStreaming jdk1.4.2_10 DerbyNetClient 
derbynetmats:derbynetmats 2006-05-06 17:37:39 ***
1 del
< java.sql.SQLException: A communication error has been detected. Communication 
protocol being used: Reply.fill(). Communication API being used: 
InputStream.read(). Location where the error was detected: insufficient data. 
Communication function detecting the error: *. Protocol specific error codes(s) 
TCP/IP SOCKETS 
2 del
< Caused by: org.apache.derby.client.am.DisconnectException: A communication 
error has been detected. Communication protocol being used: Reply.fill(). 
Communication API being used: InputStream.read(). Location where the error was 
detected: insufficient data. Communication function detecting the error: *. 
Protocol specific error codes(s) TCP/IP SOCKETS 
2a1,2
> java.sql.SQLException: Insufficient data while reading from the network - 
> expected a minimum of 6 bytes and received only -1 bytes.  The connection has 
> been terminated.
> Caused by: org.apache.derby.client.am.DisconnectException: Insufficient data 
> while reading from the network - expected a minimum of 6 bytes and received 
> only -1 bytes.  The connection has been terminated.
Test Failed.
*** End:   SuicideOfStreaming jdk1.4.2_10 DerbyNetClient 
derbynetmats:derbynetmats 2006-05-06 17:37:44 ***

I guess that this difference may be caused by "DERBY-850 - Internationalize 
client/org/apache/derby/jdbc classes.".
I think this difference is no problem and willing to adopt new error messages 
in .out file.

I suspend committing this patch for days to listen comments from others.

> Improve streaming of large objects for network server and client
> ----------------------------------------------------------------
>
>          Key: DERBY-326
>          URL: http://issues.apache.org/jira/browse/DERBY-326
>      Project: Derby
>         Type: Improvement

>   Components: Network Client, Performance, Network Server
>     Reporter: Kathey Marsden
>     Assignee: Tomohito Nakayama
>  Attachments: ClobTest.zip, DERBY-326.patch, DERBY-326_2.patch, 
> DERBY-326_3.patch, DERBY-326_4.patch, DERBY-326_5.patch, 
> DERBY-326_5_indented.patch, DERBY-326_6.patch, DERBY-326_7.patch, 
> DERBY-326_8.patch, ReEncodedInputStream.java.modifiedForLongRun
>
> Currently the stream writing  methods in network server and client require a  
> length parameter. This means that we have to get the length of the stream 
> before sending it. For example in network server in EXTDTAInputStream we have 
> to use getString and getbytes() instead of getCharacterStream and 
> getBinaryStream so that we can get the  length.
> SQLAM Level 7 provides for the enhanced LOB processing to allow streaming 
> without indicating the length, so, the writeScalarStream methods in
> network server DDMWriter.java and network client Request.java can be changed 
> to not require a length.
> Code inspection of these methods seems to indicate that while the length is 
> never written it is used heavily in generating the DSS. One strange thing is 
> that it appears on error, the stream is padded out to full length with zeros, 
> but an actual exception is never sent.  Basically I think perhaps these 
> methods need to be rewritten from scratch based on the spec requirements for 
> lobs.
> After the writeScalarStream methods have been changed, then EXTDAInputStream 
> can be changed to properly stream LOBS. See TODO tags in this file for more 
> info.  I am guessing similar optimizations available in the client as well, 
> but am not sure where that code is.

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

Reply via email to