Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=sbcglobal.net;
  h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=ycFdYAr143vljJ4DWhOK4uVeR0KpL7vkbJOR28pB3nWMVyMjRwdMlXio1m68G72Bq6ejPF3pZStI4PqvATKiy9fuLNY9j108v0C4/luZBkSIPLbj+P7VN2roxfCuwxYIXCitY3qz4VPhJK8JA2OSqe9R4psHw9fPKVxnGRnOMmE=
  ;
Message-ID: <4F3A8C58.9010909@sbcglobal.net>
Date: Tue, 14 Feb 2012 08:31:20 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE
References: 
 <CAK04dvZ+nNOni=QvgSz=Be3t4sAj25aAyVQQULrfVx-tbAjQHg@mail.gmail.com>
 <CAK04dvaWb7ojvJKjZVF9-6EQyOdCWLiE4+7Jjzq-L3mqDPZQzQ@mail.gmail.com>
In-Reply-To: 
 <CAK04dvaWb7ojvJKjZVF9-6EQyOdCWLiE4+7Jjzq-L3mqDPZQzQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Adriano Oliveira wrote:
> Hi,
> 
> Could you please help me with compress?
> 
> Why i aways got an StackOverflowError exception when i try to run CALL 
> SYSCS_UTIL.SYSCS_COMPRESS_TABLE() ?
> 
> I have about 8 tables (consuming 3Gb of disk space) and compress never 
> got success to compress all of then, I'm using the java application 
> CompressAll listed in this 
> wiki http://wiki.apache.org/db-derby/DatabaseConsistencyCheck
> 
> Thans,
> --Adriano
> 
> 
> Java exception: ': java.lang.StackOverflowError'.
>    Causado por: StackOverflowError
> ------------------------------------------------------------------------------------------------
> java.lang.RuntimeException: Java exception: ': 
> java.lang.StackOverflowError'.
> at 
> ... removed stack
> 
Could you post a full copy of the derby.log containing the error. 
Sometimes that log has more information, or previous info in it is 
useful.  Best case would be to log a JIRA as Bryan suggests and put
all info into it.

as a workaround you might try doing one table at a time and committing, 
then going on to the next table.  It should be easy to alter the example
java code, let us know if you need help with that.

This may also reduce the total amount of disk space needed for the
operation.  This operation basically creates a new table and indexes and 
it can not remove the files associated with the old tables and indexes 
until a commit happens.


Also is it at all possible that you
are doing other work in the same transaction?

The DropOnCommit calls are going to
come 1 for each associated object that has a file in derby.  This will
include 1 for each table, index, constraint, and foreign key.  You say
you have about 8 tables, do you have an unusual number of objects
associated with these tables?


Without a repro it is hard to say what is going on.  If I had the db
first thing I would try to see if the problem still exists if there
is not data in the tables, to see if the problem is related to size
of tables, or to ddl of the the tables.

My first question would be if the drop on commit
calls are just too many, or if there is a buggy loop somewhere.