[
https://issues.apache.org/jira/browse/DERBY-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-3009:
--------------------------------------
Attachment: derby-3009-1a.diff
The problem appears to be that references to table descriptors are leaked by
AlterTableConstantAction (via the fields td and activation). The
AlterTableConstantAction object isn't eligible for garbage collection until the
corresponding statement has been evicted from the statement cache. The table
descriptors may be of considerable because of all the constraints.
The attached patch (derby-3009-1a.diff) clears these fields once the constant
action has been executed. With the patch, I could run the repro with 16 MB heap
space without seeing out of memory errors.
> Out of memory error when creating a very large table
> ----------------------------------------------------
>
> Key: DERBY-3009
> URL: https://issues.apache.org/jira/browse/DERBY-3009
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.2.0
> Environment: Win XP Pro
> Reporter: Nick Williamson
> Assignee: Knut Anders Hatlen
> Labels: derby_triage10_5_2
> Attachments: DERBY-3009.zip, derby-3009-1a.diff
>
>
> When creating an extremely large table (c.50 indexes, c.50 FK constraints),
> IJ crashes with an out of memory error. The table can be created successfully
> if it is done in stages, each one in a different IJ session.
> From Kristian Waagan:
> "With default settings on my machine, I also get the OOME.
> A brief investigation revealed a few things:
> 1) The OOME occurs during constraint additions (with ALTER TABLE ...
> ADD CONSTRAINT). I could observe this by monitoring the heap usage.
> 2) The complete script can be run by increasing the heap size. I tried with
> 256 MB, but the monitoring showed usage peaked at around 150 MB.
> 3) The stack traces produced when the OOME occurs varies (as could be
> expected).
> 4) It is the Derby engine that "produce" the OOME, not ij (i.e. when I ran
> with the network server, the server failed).
> I have not had time to examine the heap content, but I do believe there is a
> bug in Derby. It seems some resource is not freed after use."
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
