Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ixjonez@gmail.com designates
 64.233.182.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=HhdeNwXyKz707hnsxTHkwpD2tUNAO8BuPkCh/7CxD67hjIf8bhPf2kEbkLEdeqjwdeTraiV62brZBYUDPrq4mKWlIeLBcHViQza5GVDBbZNaQEBxQfmOJvnXGWzifYsy3bixWpXcumDp8Y+OoKLowCjBJEVS390ZQZx5JYiN6iQ=
Message-ID: <29a761a00601030540kf39e906h41d3ed2142d676af@mail.gmail.com>
Date: Tue, 3 Jan 2006 08:40:58 -0500
From: Brian Moseley <bcm@osafoundation.org>
Sender: ixjonez@gmail.com
To: jackrabbit-dev@incubator.apache.org
Subject: Re: corrupted root node state
In-Reply-To: <90a8d1c00601030240n3a1d1041gbd62db83f9a6609c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <29a761a00601020302q15c6ee39s9252356d05773672@mail.gmail.com>
	 <90a8d1c00601030240n3a1d1041gbd62db83f9a6609c@mail.gmail.com>

On 1/3/06, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:

> currently i can only think of two possible explanations:
> 1. you're trying to read data which what was written with an older jackra=
bbit
>     version. the serialization format has changed a while ago (svn r32984=
1).
> 2. the power cycle must have happened during the jdbc commit call
>     (SimpleDbPersistenceManager line 419) which in turn caused a corrupte=
d
>     node state. although this seems rather unlikely...

hm, we've been using r354348 for several weeks, and before that
r330363, so i don't think we're a victim of #1.

i've written a tool to rebuild my repository based on a list of nodes
that i know should exist. in the process, i've made an interesting
discovery: when the root node has 1179 or fewer children, there is no
problem deserializing its node state, but when it has 1180 or more
children, the error occurs.

i have made this happen on my development platform, so now the problem
seems more like a limit on the number of child nodes for the root
node, or a limit on the size of the derby column.

a google search told me that the default size for a derby blob is 1M.
i modifed the derby.ddl file to make the blob 10M, rebuilt an empty
repository and inserted 1180 nodes, only to get the deserialization
error again.

(due to the steps i take to insure an empty repository with my custom
node types imported into it, i'm not 100% sure that the 10M change
made it in to the final repository. i've been trying to use ij to
examine the table, but i'm having problems getting ij to find the
database.)

> if you can provide me the data (derby database) i'll investigate further.

thanks. i'm checking into whether or not our privacy policy allows me
to share the database with you.