[ http://issues.apache.org/jira/browse/DERBY-1454?page=all ]
Bryan Pendleton updated DERBY-1454:
-----------------------------------
Attachment: derby-1454.diff
Attached 'derby-1454.diff' is a proposed patch for this issue.
The patch corrects the two splitQRYDTA calls to use > rather
than >= to determine if the DSS needs to be split.
The patch also contains a new test case in derbynet/prepStmt.java
to demonstrate the bug and its fix.
Please review. Thanks!
> DRDA Protocol Exception when DSS is exactly 32767 in length
> -----------------------------------------------------------
>
> Key: DERBY-1454
> URL: http://issues.apache.org/jira/browse/DERBY-1454
> Project: Derby
> Type: Sub-task
> Components: Network Server
> Versions: 10.2.0.0, 10.1.3.0, 10.1.3.1
> Reporter: Bryan Pendleton
> Assignee: Bryan Pendleton
> Attachments: derby-1454.diff, newBug.java
>
> The server is disconnecting the client connection. Client is sending a
> CNTQRY, the server is receiving it
> and then server disconnects the client. When I start the server, after a
> while, I see the message
> agentThread[DRDAConnThread_4,5,main].
> Further debugging, this message gets printed out because of the agentError
> that is thrown in splitQRYDTA.
> The error seems to come from this part of the code in splitQRYDTA, It hits
> the temp.length==0 case.
> private void splitQRYDTA(DRDAStatement stmt, int blksize) throws
> SQLException,
> DRDAProtocolException
> {
> // make copy of extra data
> byte [] temp = writer.copyDSSDataToEnd(blksize);
> // truncate to end of blocksize
> writer.truncateDSS(blksize);
> if (temp.length == 0)
> agentError("LMTBLKPRC violation: splitQRYDTA was " +
> "called to split a QRYDTA block, but the " +
> "entire row fit successfully into the " +
> "current block. Server rowsize computation " +
> "was probably incorrect (perhaps an off-by-" +
> "one bug?). QRYDTA blocksize: " + blksize);
> stmt.setSplitQRYDTA(temp);
> }
> In doneData and writeFDODTA, it looks like if (writer.getDSSLength() >=
> blksize) , then the splitQRYDTA
> is called. From testing, it seems like they are hitting an edge case, where
> the writer.getDSSLength()
> is equal to blksize and this DSS is the only dss in the send buffer.
--
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
