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 03:55:57 GMT
    [ http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12355684 ] 

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

> Does the server need to associate the data with the result set and wait for the next
CNTQRY, or can it send another block in a continuation DSS immediately after sending the first
one? 

I'm sorry; I'm finding these DRDA specs rather hard going. 

For example, I can't find the phrase "continuation DSS" in any of the 3 DRDA specs.

I did find some things that seemed relevant, though:
- Sections 4.4.6.2 and 7.21.1.1 in Volume 1 seem relevant to this issue, as does the MAXBLKEXT
definition in Volume 3
- On page 477 of volume 3: "Answer set data may also be returned in one or more QRYDTA reply
data objects"
- On page 476 of volume 3: "Possibly, additional query blocks, limited in number by the value
of the MAXBLKEXT parameter of OPNQRY, each containing a QRYDTA reply data object"
- On page 137 of volume 1: "If the application server cannot return all the requested rows
because it has used up all the query blocks it is allowed to, according to the maxblkext parameter,
then the DRDA rowset is incomplete. The application server returns one or more QRYDTAs with
the rows it has fetched, and expects the CNTQRY request from the application request either
to complete the DRDA rowset (or, optionally) to reset it."
- Volume 3 says that the MAXBLKEXT value defaults to 0, which I think means that, by default,
the server can only return a single QRYDTA block at a time.
- On page 137 of volume 1: "Note: At any time after the application requester has sent the
OPNQRY command and the application server has successfully processed it, and before the application
server has sent an ENDQRYRM reply message, the application requester can send a Close Query
(CLSQRY) command..."
- On page 435 of volume 1: "If the space remaining in the query block cannot contain the complete
base rows, only that part of the
row data that can fit in the remainder of the exact query block is added to the query block.
If this is the first row added to
the exact query block, then additional exact query blocks are generated to contain the remainder
of the base row data. If this
is not the first row added to the exact query block, then either a partial row is returned
in the last exact query block or
extra query blocks can be generated to contain the remainder of the row (and possibly, additional
rows) as allowed by the maxblkext
parameter."

So, I'm guessing that by "continuation DSS" you mean the creation of a 2nd-through-nth QRYDATA
block. If so, then yes, I believe that
the server is allowed to do this, but only if the client has provided a non-zero MAXBLKEXT
parameter.

Once the server has generated (MAXBLKEXT + 1) QRYDATA blocks, if it has not yet exhausted
the rows to be returned, then
it must halt the data return process in mid-row, place the query into "suspended" state, and
wait for the client to
send either a CNTQRY or a CLSQRY.

I do not believe that the client is allowed to send any commands other than CNTQRY or CLSQRY;
those are the only legal options.

Please help me better understand the terminology that these DRDA specs are using.


> 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


Mime
View raw message