Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <15189026.52171276766064442.JavaMail.jira@thor>
Date: Thu, 17 Jun 2010 05:14:24 -0400 (EDT)
From: "Kristian Waagan (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1595) Network server fails with
 DRDAProtocolException if a BLOB with size 2147483647 is streamed from
 client
In-Reply-To: <29608534.1153923733879.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879714#action_12879714 ] 

Kristian Waagan commented on DERBY-1595:
----------------------------------------

Hi Knut,

1) Here's what I got:

 a) DRDA vol 3, page 300:
   "The length of the extended total length field must be a multiple of two bytes, and it cannot be longer than necessary to express the length of the object's data."

 b) .../client/net/Request:
        // according to Jim and some tests perfomred on Lob data,
        // the extended length bytes are signed.  Assume that
        // if this is the case for Lobs, it is the case for
        // all extended length scenarios.

  It sounds reasonable to expect that the code never sends negative lengths, but:
    - negative values may be reserved for a special purpose
    - the DRDA spec may have made a wrong turn in this area (i.e "wasting space" by using signed instead of unsigned)
    - since the client only sends signed positive values that are small enough so that the most significant bit isn't used, the difference between client and server doesn't cause problems
    - if the server is correct, our client is breaking the spec for  a series of ranges of LOB lengths (point a, the client uses 0x7FFFL, 0x7FFFFFFF and 0x7FFFFFFFFFFF). This doesn't matter, as the server doesn't seem to enforce point a.
   (- btw, I haven't investigated if the extended length bytes are used when transferring data from the server to the client)

  To move on with the reported issue, I have logged DERBY-4702 to track further discussion of this topic.

2) No, I'm not. This is more like an assert, and I'd rather have it fail than to silently ignore the most significant parts of the long.

> Network server fails with DRDAProtocolException if a BLOB with size 2147483647 is streamed from client
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1595
>                 URL: https://issues.apache.org/jira/browse/DERBY-1595
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions: 10.2.1.6
>            Reporter: Andreas Korneliussen
>            Assignee: Kristian Waagan
>            Priority: Minor
>             Fix For: 10.7.0.0
>
>         Attachments: derby-1595-1a-client_write6bytes.diff
>
>
> When executing a program which inserts a BLOB of size 2GB-1, the Network server fails with DRDAProtocolException.  This happens before it starts handling the actual LOB data:
> java org.apache.derby.drda.NetworkServerControl start
> Apache Derby Network Server - 10.2.0.4 alpha started and ready to accept connections on port 1527 at 2006-07-26 14:15:21.284 GMT
> Execution failed because of a Distributed Protocol Error:  DRDA_Proto_SYNTAXRM; CODPNT arg  = 0; Error Code Value = c
> org.apache.derby.impl.drda.DRDAProtocolException
>         at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:441)
>         at org.apache.derby.impl.drda.DDMReader.readLengthAndCodePoint(DDMReader.java:554)
>         at org.apache.derby.impl.drda.DDMReader.getCodePoint(DDMReader.java:617)
>         at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA_work(DRDAConnThread.java:4072)
>         at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA(DRDAConnThread.java:3928)
>         at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(DRDAConnThread.java:3806)
>         at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:3640)
>         at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:928)
>         at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:254)
> null
> org.apache.derby.impl.drda.DRDAProtocolException
>         at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:441)
>         at org.apache.derby.impl.drda.DDMReader.readLengthAndCodePoint(DDMReader.java:554)
>         at org.apache.derby.impl.drda.DDMReader.getCodePoint(DDMReader.java:617)
>         at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA_work(DRDAConnThread.java:4072)
>         at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA(DRDAConnThread.java:3928)
>         at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(DRDAConnThread.java:3806)
>         at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:3640)
>         at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:928)
>         at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:254)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.