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 Sat, 26 Nov 2005 16:03:56 GMT
    [ http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12358557 ] 

Bryan Pendleton commented on DERBY-614:

After stepping through the current code carefully in the debugger, and trying several failed
attempts at changes, I learned several more things:

First, as Kathey observed on the mailing list, qryrowset is commonly 0 when clients perform
a fetch of result set data. This means that the "while" loop in writeFDODTA usually runs exactly
one time, and it is the responsibility of the "while" loop in writeQRYDTA to compose the implicit
row set for return. I do think that it would be possible to push this behavior down into writeFDODTA
and have a single "while" loop handle all these cases, but I also think that writeFDODTA is
already complicated enough, so I chose instead to keep the current behavior, to be more surgical
in my changes, and to document as best I could what is going on.

Second, test "big.sql" in the lang suite does a pretty good job of exposing a lot of the interesting
behaviors of this part of the code.

Third, as Kathey observed on the mailing list, the new member variable to hold the split data
between client requests belongs on the DRDAResultSet, not on the DRDAStatement. I'm still
not really sure I understand this business about a statement having multiple current result
sets, but the implementation is much more natural with that change.

Fourth, it appears that the current code has the behavior that, when sending the remainder
data for a split row in a subsequent QRYDTA block, no additional rows are added to an implicit
result set for that QRYDTA block. Instead, the remainder data is placed into the QRYDTA block
and immediately returned, and a subsequent CNTQRY/QRYDTA pair is needed to start fetching
additional rows. This had completely escaped me during "code reading", but it is the whole
point of the "moreData=false" after calling splitQRYDTA from writeFDODTA.

Fifth, with respect to EXTDTA and split query data, the behavior of the current code appears
to be "we send the EXTDTA for a particular row after the QRYDTA which contains the *end* of
this row." I have tried to retain this behavior in the new code. One interesting case is when
a row must be split across not just 2, but 3 QRYDTA blocks; in this case the EXTDTA needs
to be sent after the 3rd such block; that is the reason for the extra "if" statement in writeQRYDTA.

Lastly, I'm still not sure I understand how LMTBLKPRC is supposed to interact with callable
procedure statements, nor do I understand what  would cause the qryrtndta field to be set
to FALSE, but I think that my changes don't materially affect those cases, and the new code
should have generally the same behaviors in those cases as the old code.

I'm doing some final testing, and should post my patch shortly.

> 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, spec.html, 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