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