#3 OutOfMemoryException When the id-column-name is shared

[adamb]

I have the same problem Pierre-Luc Dupont reported in march. Here is the test I'm writing:

@Test public void catalogTest() throws Exception {
File configpath = getConfigpath();
Properties props =
DBUtils.getHSQLDBInMemoryDBConnection("testdb");
DBUtils db = initDB(props);

GSATestUtils.getGSATestUtils().initializeMinimalConfigpath(configpath,
"/ProductCatalogRepository",
new String[] { "fab/tests/productCatalog.xml" },
props, null, null, null, true);

Nucleus n = startNucleus(configpath);

MutableRepository r =
(MutableRepository)n.resolveName("/ProductCatalogRepository");

assertNotNull(r);

n.stopService();
db.shutdown();
}

And the error is:
**** Error ven. juin 13 15:52:46 CEST 2008 1213365166310 /
atg.nucleus.NucleusResources->cantResolveComponent : Unable to resolve
component /ProductCatalogRepository java.lang.OutOfMemoryError: Java
heap space

After searching, I reduced the repository description file to the minimalist version which don't work. Here is an XML causing the problem
:

<table name="mycategory" type="primary" id-column-name="category_id">
<property name="id" column-name="category_id"
data-type="string" />
</table>

And the one solving it :

<table name="mycategory" type="primary"
id-column-name="category_idxxxxx">
<property name="id" column-name="category_id"
data-type="string" />
</table>

When the id-column-name is equal to one column-name of the table, the error occurs. However, the original productCatalog.xml contains a lot of this kind of reference and ATG works well with it. The problem occurs only with ATG Dust.

I hope my contribution will help to solve the problem.

[adamb]

Logged In: YES
user_id=1498081
Originator: YES

It looks like this is actually caused by a bug in the GSA itself.
I filed an ATG bug 152381 to track it.
The issue is that the definition above creates a circular reference
in the table column definition. Normally that's not used in the GSA
unless you ask the GSA to generate SQL statements for you.
That's how dust gets it's SQL statement so we're dependent on that feature.
Because there is a circular reference it attempts to generate a CREATE TABLE
statement that lists that "catagory_id" column and infinite number of times and eventually
runs out of memory.

The workaround is to either:
1. Don't share the id column with a property
or
2. Add an extra "dummy" property at the end.

If there is more than one property defined for the given table it looks like
it'll break the loop in the GSA which causes the OOM error.

Given the workaround (I prefer #2 above) and the fact that the code is actually in the repository
so it can't be modified by this project, I'm going to mark this bug as won't fix.