[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332240 ]
A B commented on DERBY-614:
---------------------------
It looks to me like the problem is that, in the "splitQRYDTA" method that
Kathey mentioned, the server reads a codepoint and _assumes_ it's a CNTQRY
without explicitly checking for it:
// read CNTQRY - not sure why JCC sends this
correlationID = reader.readDssHeader();
int codePoint = reader.readLengthAndCodePoint();
DRDAStatement contstmt = parseCNTQRY();
The server reads the codePoint and then assumes that a CNTQRY follows--but it
looks like that's not a valid assumption. In this case, the app wants to stop
reading the data early, so instead of sending a CNTQRY the client ends up
sending a CLSQRY. The CLSQRY codepoint is read, but then parseCNTQRY() is
called, so the server is looking for CNTQRY data (which expects a BLKSZ) and
instead gets CLSQRY data (which has no BLKSZ), hence the missingCodePoint
exception.
I looked at the DDM Manual and found the following statements:
[ LMTBLKPRC ]: A query is terminated any time the CLSQRY command suspends it.
[ EXCSQLSTT ]: After the EXCSQLSTT or each subsequent CNTQRY command, each
result set is suspended
unless some condition terminates the result set (see CNTQRY (on page 234)). The
CNTQRY
command can continue a suspended result set so that the next portion of the
answer set data is
returned. A result set is terminated anytime the CLSQRY command is received and
processed.
[ LMTBLKPROC ]: The following examples show some of the valid responses to the
CLSQRY command:
• If the query is suspended under normal conditions, then an SQLCARD object
is returned.
I'm assuming that in this case "the query is suspended under normal conditions"
(at least, I don't see anything in the traces to indicate otherwise), so based
on the above lines from the DDM manual, it seems like the server should be
allowing for a CLSQRY to be received in the middle of splitQRYDTA and, if it
receives one, should perform normal CLSQRY processing (ultimately returning a
SQLCARD).
That said, though, I spent a good chunk of time trying to force this situation
to occur, and I wasn't able to do so. That doesn't mean it's not possible,
just that I didn't have any luck reproducing the problem on my own.
> Execution failed because of a Distributed Protocol Error
> --------------------------------------------------------
>
> Key: DERBY-614
> URL: http://issues.apache.org/jira/browse/DERBY-614
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.1.0
> Environment: Linux 2.4, Sun JDK 1.4.2_07, full SYSINFO will be attached.
> Reporter: Bryan Pendleton
> Attachments: clientSideTrace.txt, clientStack.txt, derbyTrace.txt,
> query.txt, serverSideTrace.txt, sysinfo.derby
>
> I am intermittently receiving Distributed Protocol Error exceptions in my
> client code. Simultaneously,
> my derby.log is recording Distributed Protocol Error exceptions on the server
> side.
> I cannot reliably reproduce this problem.
> However, the problem always occurs in the same section of my application, so
> I can at least
> describe that section of my application. (I'll do so in an attachment).
> Here is the error I receive on the server side. Sometimes, the CODPNT is 2116
> and the
> Error Code Value is 1d, rather than 2114 and e.
> 2005-10-05 02:10:23.663 GMT Thread[DRDAConnThread_2,5,main] (DATABASE =
> BuildFar
> m), (DRDAID = GA0A0026.P7E6-4182154075488704215{136532}), Execution failed
> becau
> se of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 2114;
> Er
> ror Code Value = e
> Execution failed because of a Distributed Protocol Error:
> DRDA_Proto_SYNTAXRM;
> CODPNT arg = 2114; Error Code Value = e
> 2005-10-05 02:10:23.663 GMT Thread[DRDAConnThread_2,5,main] (DATABASE =
> BuildFar
> m), (DRDAID = GA0A0026.P7E6-4182154075488704215{136532}), null
> null
> org.apache.derby.impl.drda.DRDAProtocolException
> at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(Unknown
> Sourc
> e)
> at org.apache.derby.impl.drda.DRDAConnThread.missingCodePoint(Unknown
> So
> urce)
> at org.apache.derby.impl.drda.DRDAConnThread.parseCNTQRY(Unknown
> Source)
> at org.apache.derby.impl.drda.DRDAConnThread.splitQRYDTA(Unknown
> Source)
> at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(Unknown
> Source)
> at org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(Unknown
> Source)
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
> Sou
> rce)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
--
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
