db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-614) Execution failed because of a Distributed Protocol Error
Date Tue, 25 Oct 2005 16:09:55 GMT
    [ 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:
>  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.
> 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
> 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:
For more information on JIRA, see:

View raw message