[FRG-39] java OutOfMemoryError: Java heap space, while testing casts

[dynamobi-build]

[reporter="schoi", created="Tue, 14 Feb 2006 16:31:58 -0500 (GMT-05:00)"] Attached the sql file which will repro the problem.

Basically, selecting all the columns of a table one by one, casting to every different type.

Failure:
-----------
0: jdbc:farrago:> SELECT t11_2, CAST (t11_2 AS numeric(8,4)) FROM CST.alltypes;
Error: java.lang.OutOfMemoryError: Java heap space (state=,code=0)
net.sf.farrago.util.FarragoUtil$FarragoSqlException: java.lang.OutOfMemoryError: Java heap space

0: jdbc:farrago:> SELECT t11_2, CAST (t11_2 AS numeric(6,2)) FROM CST.alltypes;
Error: java.lang.OutOfMemoryError: Java heap space (state=,code=0)
net.sf.farrago.util.FarragoUtil$FarragoSqlException: java.lang.OutOfMemoryError: Java heap space

[dynamobi-build]

[author="schoi", created="Tue, 14 Feb 2006 16:32:48 -0500 (GMT-05:00)"] repro'ing sql

[dynamobi-build]

[author="jvs", created="Tue, 14 Feb 2006 20:18:00 -0500 (GMT-05:00)"] Wow, Sunny, I didn't know you spoke Russian? Or are those copied from Anton and Inna?

Anyway, I can't reproduce it, but I suspect the problem is that by default we don't put a limit on the plan cache, and you're probably bumping into it with so many statements in one script. It definitely gets slow towards the end for me. If you can reproduce it easily, here's the procedure to verify this hypothesis.

alter system set "codeCacheMaxBytes"=min;

then run what you usually do to reproduce. If it passes, my guess is correct. With this setting, we'll discard plans from the cache immediately.

Note: I don't have the very latest code.

[dynamobi-build]

[author="schoi", created="Tue, 14 Feb 2006 20:50:27 -0500 (GMT-05:00)"] not a single word of Russian :). These are from BB's calc test suite.

Yes, it passes with this setting:
alter system set "codeCacheMaxBytes"=min;

So I can close this JIRA and just add this to the script?

[dynamobi-build]

[author="jvs", created="Tue, 14 Feb 2006 21:50:20 -0500 (GMT-05:00)"] Yes, but we're likely to encounter this again in other long scripts. Maybe for LucidDB tests, we should just make min the default.

If you look in FarragoTestCase.setUp(), you'll see that it first sets codeCacheMaxBytes to min, and then to max. This has the effect of discarding all plans from the cache, but then resetting to max so that for the duration of each script, they will accumulate. This is probably the right thing for Farrago, where we often want to be testing statement re-execution. But for typical LucidDB queries, plan caching is of limited use (it's mostly only important for metadata queries, which all follow the same pattern). So maybe in LucidDbSqlTest, you can override it to leave it at min instead.

[dynamobi-build]

[author="schoi", created="Mon, 27 Feb 2006 17:25:41 -0500 (GMT-05:00)"] luciddb/test/src/com/lucidera/luciddb/test/SqlTest.java now executes "alter system set "codeCacheMaxBytes" = min" before any sql scripts.