Kathey,
 
I ran the lang/largeCodeGen.java with PRINT_FAILURE_EXCEPTION  set to true as follows:
>java -Dverbose=true -Djvmflags="-mx512M -ms512M" -Dframework=DerbyNetClient
org.apache.derbyTesting.functionTests.harness.RunTest lang/largeCodeGen.java
 
and got the following

MasterFileName = master/largeCodeGen.out
15a16,18
> java.sql.SQLException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error
. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_length (65577 > 65535) in generated class
org.apache.derby.exe.ac46a08075x010bx203axd010x000050a9065e9.
> Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Try
 rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_length (65577 > 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x000050a9065e9.
>       ... 4 more
19 del
< PASS: IN clause with 97000 parameters
20 del
< PASS: PREPARE: IN clause with 98000 parameters
21 del
< PASS: IN clause with 98000 parameters
22 del
brawny src/NightlyBuildResults.2006-05-10> ls
changes.txt  ibm142_largeData  test.txt  update.txt
brawny src/NightlyBuildResults.2006-05-10> tail -f test.txt
27a35,37
> java.sql.SQLException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error
. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:fillResultSe
t code_length (69127 > 65535) in generated class org.apache.derby.exe.ac46a08075
x010bx203axd010x000050a9065e11.
> Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Try
 rewriting the query to remove complexity. Eliminating many duplicate _expression_
s or breaking up the query and storing interim results in a temporary table can
often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s)
exceeded: method:fillResultSet code_length (69127 > 65535) in generated class
org.apache.derby.exe.ac46a08075x010bx203axd010x000050a9065e11.
>       ... 3 more
28 add
> java.sql.SQLException: Java exception: ': java.lang.OutOfMemoryError'.
> Caused by: org.apache.derby.client.am.SqlException : Java exception: ': java.lang.OutOfMemoryError'.
>       ... 3 more
Test Failed.

Thanks,
Raman
 
On 5/5/06, Kathey Marsden (JIRA) <derby-dev@db.apache.org> wrote:
   [ http://issues.apache.org/jira/browse/DERBY-216?page=comments#action_12378176 ]

Kathey Marsden commented on DERBY-216:
--------------------------------------

With revision 37644 I fixed the run to run differences and at that time the test passed with both embedded and client on Windows.  I never tried on Linux.

With revision 377609 Dan was able to move the number of parameters in the in list query from 3400 to 97000 (amazing). I don't know if it passed with client at that time.

Raman's testing shows that client fails before 97000 with client.
Raman  what is the highest number it goes to with client and what is the error and stack trace when it fails? In the test there is a  boolean PRINT_FAILURE_EXCEPTION  that you will have to change to see the failure.



> expand largeCodeGen.java test
> -----------------------------
>
>          Key: DERBY-216
>          URL: http://issues.apache.org/jira/browse/DERBY-216
>      Project: Derby
>         Type: Sub-task

>   Components: Test
>     Reporter: Kathey Marsden

>
> the largeCodeGen test needs to be expanded to include other cases that genreate large amounts of byte code.
> For example:
>      large in clause
>      large insert statement that inserts many rows
>      sql statements with large constant values
> It is best if the verious tests just use a variable that can be bumped higher and higher for testing and if individual cases are isolated.
> Possible approaches, think of ways to make sql statements really big that will take different code paths.
> Look in the code for instances of statementNumHitLimit and create cases that pass through that code.  Those cases may pass but the hope is to get rid of these calls in favor of splitting  the code in a centralized way, so add the tests to largeCodeGen even if they don't fail.
>

--
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




--
Ramandeep Kaur
[EMAIL PROTECTED]

Reply via email to