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 Mon, 12 Dec 2005 18:00:46 GMT
    [ http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12360229 ] 

Bryan Pendleton commented on DERBY-614:
---------------------------------------

After re-reading the changes and stepping through the code again, I believe that the patch
is correct, and the removal of the finalizeChain() call from splitQRYDTA is proper. Here is
my reasoning:

The previous flow-of-control for a split QRYDTA block was that writeFDODTA assembled a large
row, which splitQRYDTA then split across multiple QRYDTA blocks, sending each of those blocks
and waiting for the next CNTQRY message before continuing. By the time that splitQRYDTA returned,
any QRYDTA blocks containing partial portions of that large row had been sent to the client,
and the current QRYDTA block was filled with the final bytes of the split row. The finalizeChain
call in splitQRYDTA was necessary because that was how the partial QRYDTA blocks were sent
to the client.

In the new flow-of-control, splitQRYDTA does not actually send the QRYDTA block to the client,
nor does it wait for the CNTQRY from the client. Instead, all sending and receiving happens
in the "normal" location in processCommands. splitQRYDTA arranges to split the data, records
the partial data in the result set, and control "pops" all the way back out to processCommands.
The QRYDTA block which contains the partial row data is sent by the finalizeChain() call in
processCommands, at line 897.

In all cases, in both old and new code, externalized data was sent after the QRYDTA containing
the last remainder bytes of the split row, by calling writeEXTDTA from writeQRYDTA.

Thus the old code had two finalizeChain calls, because a QRYDTA block might be sent either
by processCommands, or by splitQRYDTA, depending on whether it contained a split row or not.
The new code has only one finalizeChain call, because all QRYDTA blocks are sent by processCommands.

One case that I had trouble exercising in my testing is that there is *also* a call to splitQRYDTA
from doneData, and perhaps in that case there is a problem? Fundamentally, I think the flow
of control will be the same: doneData calls splitQRYDTA to prepare the partial block, control
pops back out to processCommands to send the response and wait for the CNTQRY, then processLeftoverQRYDTA
will drop the remainder bytes into a subsequent QRYDTA to be sent. Still, I have not been
able to provoke such a case in my simple testing.

Are there flaws in my reasoning here? Additional test cases I should try?

Do you know of a test case which will cause splitQRYDTA to be called from doneData? 


> 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
>     Assignee: Bryan Pendleton
>  Attachments: clientSideTrace.txt, clientStack.txt, derby-614.zip, derbynetclientmats_report.txt,
query.txt, serverSideTrace.txt, spec.html, svn-diff-2005-12-04.txt, svn-status-2005-12-04.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


Mime
View raw message