db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3347) ERROR XSDB3: Container information cannot change once written
Date Wed, 16 Apr 2008 07:24:21 GMT

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

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

    Attachment: FileOffset.java

I'm not sure (since I haven't been able to reproduce the problem myself) but I don't think
you'll be able to drop the table/index. I think DROP TABLE will open the container it's about
to drop, and then it'll also read the container information stored in page 0.

I also think it is possible that the problem with mixing FileChannel operations and RandomAccessFile.seek()
can cause corruption on any page in the container, although based on the reports, it seems
like page 0 is the most likely one to be hit.

I'm attaching the program I used to track down the problem (no Derby code, only pure file
operations), FileOffset.java. It runs 10 threads that write at random positions in a file
using a FileChannel, while the main thread runs a loop with RAF.seek(0L) + sleep() + RAF.getFilePointer().
On Solaris and Linux, getFilePointer() always returns 0, but on Windows it frequently returns
other values pointing at random positions in the file (only tested with Sun's JVMs). So it
is quite possible that a write occurs at the wrong position and corrupts another page than
page 0.

The other problem (concurrent access to page 0 by container cache and page cache) can only
hit page 0, I believe.

> 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
>             Fix For: 10.3.2.2, 10.4.1.2, 10.5.0.0
>
>         Attachments: d3347-1a.diff, d3347-1a.stat, d3347-1b.diff, d3347-2a.diff, d3347-preview.diff,
d3347-preview.diff, FileOffset.java, MiniStress.zip
>
>
> 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.


Mime
View raw message