[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12355871 ]
Bryan Pendleton commented on DERBY-614:
---------------------------------------
> Could you try to change your test case and see if we might get some other
> request from the client before we get the CNTQRY or CLSQRY request for this
> result set?
It is exactly as you suspected. If I add a 2nd statement and call
's2.executeUpdate("create table foo (i int)");' at the critical time, we still
get the SYNTAXRM exception, but the details are indeed different:
- the codepoint in the exception in the server log is 0x2105, which I think is
RDBCMTOK
- the server-side trace shows that we got EXCSQLIMM rather than CLSQRY:
RECEIVE BUFFER: EXCSQLIMM (ASCII) (EBCDIC)
- the server-side stack trace is just slightly different. Rather than
parseCNTQRY calling 'missingCodePoint', which is what happens when we send a
CLSQRY, this time parseCNTQRY calls 'invalidCodePoint', which throws the
SYNTAXRM exception.
So I agree with you: the client should be able to send *any* command at this
point, so the server needs to be prepared to
handle any command. I guess this means that the server needs to be able to
fully suspend this query, holding the partial row in abeyance, such that it can
resume processing the query, starting a new QRYDTA block with the remainder of
this partial row, if the client so requests, but also be able to handle any
other command that might arrive.
I see that there is DRDAStatement.rsSuspend, which in turn calls
DRDAResultSet.suspend, but those seem to simply set a status flag; we also need
to record the contents of local variable 'temp' which is holding the remainder
of the partially-returned row, yes?
It seems that a solution should be something along the lines of:
1) when splitQRYDTA determines that it cannot fit all the data into this block,
it should attach the remainder data to the result set, suspend the statement,
and pop all the way back out to the processCommands loop
2) When a CNTQRY is received, the first thing that writeQRYDTA should do is to
look for any partial remainder data that might have been saved by step 1, and
write that data prior to writing any new data.
3) And it seems like the MAXBLKEXT parameter should figure in here as well, I
think?
It's still muddy, but it's getting much clearer.
> 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, derby-614.zip,
> 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
