Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

• Key: DERBY-491
• Type: Sub-task
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Bryan Pendleton
• Reporter: A B
• Component/s: Network Server
• Affects Version/s: 10.0.2.2, 10.1.1.0, 10.2.1.6
• Fix Version/s: 10.1.3.1, 10.2.1.6

Description

When Derby Network Server tries to return ~32K or greater data as part of the result set for a stored procedure, a protocol exception occurs and causes deallocation of the connection. Repro can be found in the "stored_proc_repro.java" file, which uses the stored procedure "BIG_COL" declared in "storedProcs.java". Both files are attached to this bug.

Comments

[A B]

Adding repro files (same as the files for DERBY-170)

[Bryan Pendleton]

This wasn't immediately clear from the stored_proc_repro.java file, but I seem to *also* get the same exception if I use the Derby Client Driver. I tweaked the reproduction code to say:

      Class.forName("org.apache.derby.jdbc.ClientDriver").newInstance();
      Connection conn = DriverManager.getConnection( "jdbc:derby://localhost:1527/testdb", "bah", "humbug");

instead of referencing the DB2JCC driver, and I get the following exception, which I assume is the same as the bug you observed:

 -=- ERROR 1 REPRODUCED:
org.apache.derby.client.am.DisconnectException: actual code point, -2 does not match expected code point, 8709
        at org.apache.derby.client.net.Reply.zThrowSyntaxError(Reply.java:1163)
        at org.apache.derby.client.net.Reply.parseLengthAndMatchCodePoint(Reply.java:1063)
        at org.apache.derby.client.net.NetStatementReply.parseOPNQRYRM(NetStatementReply.java:724)
        at org.apache.derby.client.net.NetStatementReply.parseResultSetCursor(NetStatementReply.java:400)
        at org.apache.derby.client.net.NetStatementReply.parseResultSetProcedure(NetStatementReply.java:377)
        at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:279)
        at org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:97)
        at org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:74)
        at org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:174)
        at org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1117)
        at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:1428)
        at org.apache.derby.client.am.CallableStatement.executeX(CallableStatement.java:124)
        at org.apache.derby.client.am.CallableStatement.execute(CallableStatement.java:114)
        at stored_proc_repro.main(stored_proc_repro.java:57)

[Bryan Pendleton]

Attached is a patch proposal which addresses both this bug and DERBY-492. I have also included a document which provides background information for the reviewers. The patch proposal includes new tests and master files. HOWEVER: the new tests do not pass with this patch. In order for the tests to pass, you have to have the fixes for DERBY-125 first. My hope/intention is that we can review/commit the DERBY-125 fixes first, and then I can re-visit this patch and update it and then the tests will pass. In the meantime, if you take this patch for testing, be aware that you will get a diff in the procedure test, as follows:

*** Start: procedure jdk1.4.2_06 DerbyNetClient derbynetmats:derbynetmats 2006-01-13 12:55:45 ***
941 del
< JIRA-492 successful -- no hang!
941 add
> ERROR (no SQLState): only one of the VCM, VCS length can be greater than 0
> org.apache.derby.client.am.DisconnectException: only one of the VCM, VCS length can be greater than 0
Test Failed.

[Kathey Marsden]

The change looks good. When you sync up, it would be good to add some comments about the changes to the code and include a reference to DERBY-491 and the changes.html here.

The changes.html wonderful and educational as always. I have not really worked with this low level protocol code much so it is great to have such a great tutorial included with the patch.

After reading and learning more about these issues. I really think your proposal to fill the buffer with a known value in sane builds or if derby.drda.debug=true would be very valuable. It would be interesting even to see how we do in the tests with this turned on.

[Bryan Pendleton]

Updated patch, against latest trunk. I added a few additional comments to this patch to try to explain the changes more clearly, and also I added a reference to this bug entry to help the reader find more information. Now that DERBY-125 has been committed (thanks!), the regression test passes cleanly, and I have also run the entire derbyall suite with this patch.

I think that this patch proposal is now ready for review. Kathey, Army, other interested reviewers, please have a look and tell me what you think!

[Bryan Pendleton]

Updated the comments in the regression test to explain the test behavior more clearly and accurately, and to include a pointer to this bug entry for the interested reader to get more details.

Bernt, if you have the time to look at this and commit it, that would be great!

thanks,

bryan

[A B]

For those wondering, Bryan's latest patch addreses comments I made here:

http://article.gmane.org/gmane.comp.apache.db.derby.devel/12818

Thanks as always for the phenomenal explanations in the latest version of changes.html. The new comments in the tests look good to me, and I have no other issues with the patch.

This is great work...
+1 to commit.

[Bernt M. Johnsen]

committed

[Bryan Pendleton]

Set fix version to 10.2.0.0. This bug was fixed in the trunk in January.

[Bryan Pendleton]

Re-opened to merge this fix to the 10.1 branch.

[Bryan Pendleton]

Merged the change from the trunk back to the 10.1 branch. The merge was straightforward. I verified that I could still reproduce the bug in 10.1, that the test demonstrated the bug, and that the code change fixed it.

Committed to subversion as revision 398093:
svn.apache.org/viewcvs?rev=398093&view=rev

[A B]

Issue has been fixed, tested, and ported back to 10.1, so I'm now marking it as closed. Thanks Bryan!