[ http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12357630 ]
Francois Orsini commented on DERBY-614: --------------------------------------- I have done a bit of reading on the subject (which was a great learning exercise btw) and I find Brian's approach with 1) and 2) to be appropriate. We'll need to ensure the remainder data attached to the resultset is released/freed if the CLSQRY DDM command is sent by the requester or due to some unexpected error condition (as part of ENDQRYRM) returned from the server - but that should happen as part of resultset deallocation logic.. As far as handling MAXBLKEXT in 3) - I'd say that we obviously need to take it into account since a client (requester) could set a value different than zero (i.e. other DRDA clients out there). Interestingly enough, the DDM specifications mention the following for MAXBLKEXT: "A value of zero indicates that the requester is not capable of receiving extra query blocks of answer set data. " which is the default we have right now, hence the server should not be returning extra query blocks of QRYDTA...would that also be why the client sent CLSQRY in the first place...I mean, if the client set a MAXBLKEXT of zero, then it will not expect reading further data from the server after the initial reply (just some thoughts). Now, the specs also say the following about MAXBLKEXT: "A value of minus one indicates that the requester is capable of receiving the entire result set." (am reading this as the requester will be able to receive the entire resultset without any particular limit on the number of blocks of answer set data returned by the server) - this is not very clear from the specs so not completely sure about this. Hence, should not we set '-1' as the default value of MAXBLKEXT for the Derby DRDA networkclient driver instead of zero? Since and IMHO, the (derby) server should by default try to return the entire resultset (in chunks/clocks as appropriate) to the derby networkclient which has control as far as reading more data or not (via CLSQRY) anyway. Now, in case of MAXBLKEXT limit being reached (or in MAXBLKEXT value being zero) then the server should probably terminate the query via a ENDQRYRM reply and some error condition (Severity Code). > 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
