[ http://issues.apache.org/jira/browse/DERBY-1456?page=comments#action_12427245 ] Kathey Marsden commented on DERBY-1456: ---------------------------------------
I am merging this change to 10.1 To verify reverse merged the code change for DERBY-1454 and ran the new derbynet/prepStmt.java test: e.g. svn merge -r 417032:417031 https://svn.apache.org/repos/asf/db/derby/code/branches/10.1 svn revert `svnls | grep prepStmt` where svnls is svn stat -q | sed -e 's/\\/\//g' | sed -e 's/. [ +]*//' | grep -v 'external ite m' ran derbyNet/prepStmt.java And wow what a difference! What I saw was this in the derby.log org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of Permanent Agent Error: SVRCOD = 40; RDBNAM = wombat;create=true; diagnostic msg = LMTBLKPRC violation: splitQRYDTA was called to split a QRYDTA block, but the entire row fit successfully into the current block. Server rowsize computation was probably incorrect (perhaps an off-by-one bug?). QRYDTA blocksize: 32767 at org.apache.derby.impl.drda.DRDAProtocolException.newAgentError(DRDAProtocolException.java:328) at org.apache.derby.impl.drda.DRDAConnThread.agentError(DRDAConnThread.java:429) at org.apache.derby.impl.drda.DRDAConnThread.splitQRYDTA(DRDAConnThread.java:6240) at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(DRDAConnThread.java:6173) at org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(DRDAConnThread.java:5926) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:592) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:223) 2006-08-10 14:44:11.257 GMT Thread[DRDAConnThread_2,5,main] (XID = 1121), (SESS and the client gets the perfectly reasonable: org.apache.derby.client.am.DisconnectException: Execution failed due to a distribution protocol err or that caused deallocation of the conversation. A PROTOCOL Data Stream Syntax Error was detected. Reason: 0x3 at org.apache.derby.client.net.Reply.doSyntaxrmSemantics(Reply.java:950) at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:345) at org.apache.derby.client.net.Reply.peekCodePoint(Reply.java:1009) at org.apache.derby.client.net.NetResultSetReply.parseCNTQRYreply(NetResultSetReply.java:12 9) at org.apache.derby.client.net.NetResultSetReply.readFetch(NetResultSetReply.java:38) at org.apache.derby.client.net.ResultSetReply.readFetch(ResultSetReply.java:40) at org.apache.derby.client.net.NetResultSet.readFetch_(NetResultSet.java:181) at org.apache.derby.client.am.ResultSet.flowFetch(ResultSet.java:2930) at org.apache.derby.client.net.NetCursor.getMoreData_(NetCursor.java:927) at org.apache.derby.client.am.Cursor.next(Cursor.java:155) at org.apache.derby.client.am.ResultSet.nextX(ResultSet.java:261) at org.apache.derby.client.am.ResultSet.next(ResultSet.java:240) at org.apache.derbyTesting.functionTests.tests.derbynet.prepStmt.tickleDSSLength(prepStmt.j ava:871) at org.apache.derbyTesting.functionTests.tests.derbynet.prepStmt.jira1454Test(prepStmt.java :842) at org.apache.derbyTesting.functionTests.tests.derbynet.prepStmt.main(prepStmt.java:308) I keep thinking back to that case, if this error message had not been mysteriously consumed in the user environment how easy it all would have been. Thanks Sunitha for the great fix and also to Bryan for leaving such incredibly useful breadcrumb trails in the error messages for known problem areas. So glad we can now see the breadcrumbs. > Network Server agentError calls log only to console and are hard to diagnose > ---------------------------------------------------------------------------- > > Key: DERBY-1456 > URL: http://issues.apache.org/jira/browse/DERBY-1456 > Project: Derby > Issue Type: Sub-task > Components: Network Server > Affects Versions: 10.2.0.0 > Reporter: Bryan Pendleton > Assigned To: Sunitha Kambhampati > Priority: Minor > Fix For: 10.2.0.0 > > Attachments: 1456_notes.txt, derby1456.diff.txt, derby1456.stat.txt > > > The Network Server code uses an assertion-check utility routine called > agentError() > under certain circumstances. When these agentError() calls arise, for example > as > in DERBY-1454, there is no server side logging of the error except to the > console. > The user application that hit DERBY-1454 had not been capturing console > output and there > was no clue in the derby.log, this made the problem hard to track down when > they > suddenly hit this boundary deep within their stress tests. > See also DERBY-743 for another issue with Network Server's agentError routine. -- 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
