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.193 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=pqELwaLYuNKPZDP5ZWmsNBlpBjogLFBaQEY70y9ag9osN2VMPEz1qVUb4gEnAln+cDzEbidvVQ/OhiFADPBsQwJGpEe6Zm+qYXrLXc19KFBnbRnZz2oVLWdDUBeIYhKKxv8xgZ+nIt2aZasb6MbYgjMolBuG7j8kW36dJD7NxIM=
Message-ID: <29a761a00601040659o29fc0940jef962aca63ae1aa2@mail.gmail.com>
Date: Wed, 4 Jan 2006 09:59:35 -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: <90a8d1c00601040026y4ed23942w1157130e6db3e18b@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>
	 <29a761a00601030908v5967284ag449f9ddffa7233c3@mail.gmail.com>
	 <90a8d1c00601040026y4ed23942w1157130e6db3e18b@mail.gmail.com>

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

> i could reproduce the problem easily so i don't need your data anymore, t=
hanks.
> i'll keep you posted...

question - do you have any feeling for what the problem might be?

i've spent the last couple of days trying to pin it down and haven't
had much luck. i've used ij to examine the node_data value for the
root node inside derby, and it doesn't look malformed. i've stepped
through with a debugger but been stymied when Serializer descends into
DataInputReader (as i don't have the sun jdk sources, don't know if
they're available, and couldn't get jswat to decompile rt.jar).

my current working hypothesis is that there's a bug in the stream
implementation that derby's handing to me via
ResultSet.getBinaryStream(). i find those classes extremely confusing
tho, so following what's going on inside them is extremely slow going.

anyway, every day that i don't get this problem solved is a day our
production service is down. so if anybody has ideas of what might be
happening, please share - maybe it will be the jolt i need to find the
problem and make a fix :)

(to summarize the problem - when i add a large number of nodes to the
root node, save the session and close the repository, then try to
re-open the repository, a premature EOF exception is thrown when
deserializing the root node state loaded from the derby PM,
specifically when reading the qname of the 1180th child node.)