You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Bryan Pendleton (JIRA)" <de...@db.apache.org> on 2006/03/24 23:27:35 UTC
[jira] Commented: (DERBY-1143) derbynet/prepStmt.java fails with
JCC2.6
[ http://issues.apache.org/jira/browse/DERBY-1143?page=comments#action_12371815 ]
Bryan Pendleton commented on DERBY-1143:
----------------------------------------
The failure occurs as part of the new test added for DERBY-428. That regression test is attempting to create a JDBC batch containing as many batch elements as it can. I determined the number of batch elements to put into the test by experimenting with the Derby Network Client and with JCC 2.4, but apparently JCC 2.6 supports a smaller number of batch elements than JCC 2.4 did.
Deepa is researching what the JCC 2.6 limit on number of elements in a batch is. Once we know that, we can change the DERBY-428 regression test routine in prepStmt.java so that it runs min(C, C24, C26) number of elements, where:
- C is the number of elements supported by the Derby Network Client, which is 65534
- C24 is the number of elements supported by the JCC 2.4 driver, which is 65532
- C26 is the number of elements supported by the JCC 2.6 driver (which Deepa is researching).
0x7FF is 2047 in decimal. It would be somewhat surprising if JCC 2.4 supported almost 64K batch elements in a single batch and JCC 2.6 reduced that to 2047, and it would certainly weaken the test to reduce the counter from 65532 down to 2047, but that may be the simplest solution. Since the original DERBY-428 bug only occurred when at least 9000 elements were in a single batch, setting the test limit down to 2047 would no longer test the original bug. If JCC 2.6 really supports only 2047 elements in a single batch, then we may want to enhance TestUtil so that we can tell whether we are running with JCC 2.4 or JCC 2.6, and then have the test use a different value depending on the driver in use, so that when we are running the test with the Derby Network Client we can still test that we support a large number of batch elements.
> derbynet/prepStmt.java fails with JCC2.6
> ----------------------------------------
>
> Key: DERBY-1143
> URL: http://issues.apache.org/jira/browse/DERBY-1143
> Project: Derby
> Type: Test
> Components: Regression Test Failure
> Versions: 10.2.0.0
> Environment: JCC 2.6
> Reporter: Deepa Remesh
>
> derbynet/prepStmt.java fails on Windows and Linux with Sun JDK 1.5 and JCC 2.6.
> *** Start: prepStmt jdk1.5.0_02 DerbyNet derbynetmats:derbynetmats 2006-03-22 19:46:37 ***
> 82 del
> < prepStmt Test Ends
> 82 add
> > com.ibm.db2.jcc.a.DisconnectException: More than 0x7FF chained requests not allowed. This error may be due to a batch that is greater than 32k.
> Test Failed.
> *** End: prepStmt jdk1.5.0_02 DerbyNet derbynetmats:derbynetmats 2006-03-22 19:46:59 ***
> The test passed for me with Sun JDK1.5, JCC 2.4 on Windows XP. The tinderbox runs do not show this failure. It looks like this failure is occuring only with JCC2.6.
--
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