db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tomohito Nakayama (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-326) Improve streaming of large objects for network server and client
Date Sat, 06 May 2006 09:59:34 GMT
    [ 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


Mime
View raw message