Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1021490428.1207832048633.JavaMail.jira@brutus>
Date: Thu, 10 Apr 2008 05:54:08 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3347) ERROR XSDB3: Container information
 cannot change once written
In-Reply-To: <13180882.1201127795953.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-3347:
--------------------------------------

    Attachment: d3347-2a.diff

I'm also attaching a patch (d3347-2a) for the problem with concurrent I/O operations on page 0.

This patch adds a wrapper around the methods readPage() and writePage() in RAFContainer4. If the page that is accessed is FileContainer.FIRST_ALLOC_PAGE_NUMBER, the method calls are synchronized on the container object, and therefore behave just like their non-NIO counterparts in RAFContainer. Since the code that accesses the container information on the first alloc page also is synchronized on the container object, this means that we never have two threads accessing the first alloc page concurrently. For the rest of the pages, the synchronization is not necessary, since they can only be accessed through the page cache and therefore no two threads access the same page concurrently.

I haven't run the regression tests on this patch yet.

> ERROR XSDB3: Container information cannot change once written
> -------------------------------------------------------------
>
>                 Key: DERBY-3347
>                 URL: https://issues.apache.org/jira/browse/DERBY-3347
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.3.1.4, 10.3.2.1
>         Environment: Windows 2003 Server
> Sun Java 1.6.0_03
>            Reporter: Bogdan Calmac
>            Assignee: Knut Anders Hatlen
>            Priority: Critical
>         Attachments: d3347-1a.diff, d3347-1a.stat, d3347-2a.diff, d3347-preview.diff, d3347-preview.diff
>
>
> We are using derby as an embedded DB for our data collection server. During an endurance test when we do around 270 inserts and 9 updates per second, for about a week, I ocasionally see the error below in the deby log (and nothing else beside this).
> This is a vanilla installation, we run derby embedded with no extra configuration.  I can confirm that there is no memory problem, the heap usage seems constant over time.
> Can somebody provide some more information regarding the effects of this error? By looking at the stacktrace, it looks like a checkpoint operation is aborted due to some inconsistency in the internal data structure. If the error does not repeat immediately, does it mean that the next checkpoint is successful and there is no data loss? 
> I can't provide a test case for that, the error happens after about 1-2 day of running our software. I will rerun the test with the debug jars to capture the line numbers in the stacktrace.  Also, I'm starting another test with 10.2.2.0, to see if this problem was introduced in the latest version.
> There are another two bugs referring to this error, (https://issues.apache.org/jira/browse/DERBY-2284 and https://issues.apache.org/jira/browse/DERBY-3087) but they seem to happen in response to some client action. This use case is a bit different, the client keeps inserting and updating records for several days in a steady manner and at some point the error pops up.
> And lastly, here is the exception:
> Checkpoint Daemon caught standard exception
> ------------  BEGIN ERROR STACK -------------
> ERROR XSDB3: Container information cannot change once written: was 0, now 80
> 	at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.AllocPage.WriteContainerInfo(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.FileContainer.writeHeader(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown Source)
> 	at org.apache.derby.impl.services.cache.CachedItem.clean(Unknown Source)
> 	at org.apache.derby.impl.services.cache.Clock.cleanCache(Unknown Source)
> 	at org.apache.derby.impl.services.cache.Clock.cleanAll(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.checkpoint(Unknown Source)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(Unknown Source)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(Unknown Source)
> 	at org.apache.derby.impl.store.raw.RawStore.checkpoint(Unknown Source)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.performWork(Unknown Source)
> 	at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown Source)
> 	at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown Source)
> 	at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source)
> 	at java.lang.Thread.run(Thread.java:619)
> ------------  END ERROR STACK -------------

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.