[ 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
