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: pass (nike.apache.org: local policy)
Date: Mon, 31 Mar 2008 09:47:20 +0530
From: Narayanan <V.Narayanan@Sun.COM>
Subject: Re: ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313))
In-reply-to: <47F02F3E.40807@nuix.com>
Sender: V.Narayanan@Sun.COM
To: Derby Discussion <derby-user@db.apache.org>
Message-id: <47F065D0.6010404@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <47F02F3E.40807@nuix.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)

Hi David,

You might find the following links containing earlier discussions on the 
similar issue useful,

http://www.nabble.com/invalid-checksum-tt9528741.html#a9528741

http://www.nabble.com/Derby-crash-%28urgent%29-tt16217446.html#a16265491

https://issues.apache.org/jira/browse/DERBY-2475

Narayanan

David Sitsky wrote:
> I have an intensive data-processing application which utilises Apache 
> Lucene and Derby, using 6 quad-core machines running Vista SP1 and/or 
> Vista Server 2008.
>
> I have found after 5 or 10 hours of processing, one or a couple of my 
> worker processes start reporting the following error in the derby.log 
> file:
>
> ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313))
>
> The worker process never seems to recover.  Derby locates the error, 
> reboots the database, but seems to inevitably report the same error 
> again.  It is always page 1313, and what is extra strange is it 
> doesn't matter which machine it occurs on, it is always page 1313!  I 
> know 13 is unlikely, but twice is a row must be extra unlucky. :)
>
> The quad-core machines have been configured with both hardware and 
> software raid, but the same error has been seen.  Windows does not 
> report any disk errors in the event log.
>
> The error is difficult to reproduce.  My runs typically run for 24 
> hours, involving 22 separate JVM processes spread across the machines, 
> each running their own Derby embedded database.  Sometimes I can get 
> through the run without any issues - sometimes I might see one or two 
> processes with this issue, and it seems to pick a different quad-core 
> machine each time, so the possibility of a hardware error seems like 
> unlikely, especially given it is always page 1313.
>
> I have tried both 10.3.1.4 and 10.3.2.1 with the same results.
>
> Lucene doesn't report any problems with its index, so given all the 
> above evidence, I am starting to lean more to a software issue than 
> hardware.
>
> I have attached three derby.log files from different machines.  Does 
> anyone have any ideas what might be causing this?
>