[#DERBY-3347] ERROR XSDB3: Container information cannot change once written

Derby

ERROR XSDB3: Container information cannot change once written

Created: 23/Jan/08 10:36 PM Updated: Tuesday 08:16 PM

Return to search

Component/s:

Store

Affects Version/s:

10.3.1.4, 10.3.2.1

Fix Version/s:

10.3.3.0, 10.4.1.3, 10.5.1.1

Time Tracking:

Not Specified

File Attachments:

File Name	Date Attached	Attached By	Size
d3347-1a.diff	2008-04-10 11:39 AM	Knut Anders Hatlen	18 kB
d3347-1a.stat	2008-04-10 11:39 AM	Knut Anders Hatlen	0.3 kB
d3347-1b.diff	2008-04-11 08:54 AM	Knut Anders Hatlen	18 kB
d3347-2a.diff	2008-04-10 12:53 PM	Knut Anders Hatlen	3 kB
d3347-preview.diff	2008-04-09 01:38 PM	Knut Anders Hatlen	14 kB
d3347-preview.diff	2008-04-08 03:51 PM	Knut Anders Hatlen	14 kB
FileOffset.java	2008-04-16 07:23 AM	Knut Anders Hatlen	2 kB
MiniStress.zip	2008-04-13 01:39 PM	Kathey Marsden	3 kB
releaseNote.html	2008-04-29 01:26 PM	Knut Anders Hatlen	5 kB

Environment:

« Hide

Windows 2003 Server
Sun Java 1.6.0_03

Issue Links:

Duplicate

This issue is duplicated by:

~~DERBY-2677~~ OnlineCompressTest failed reporting NullPointerException, actual problem in derby.log is a page checksum error.

~~DERBY-3411~~ OnlineBackup1 test failed with underlying error: "ERROR XSDG3: Meta-data for Container org.apache.derby.impl.store.raw.data.RAFContainer4@52325232 could not be accessed"

~~DERBY-3143~~ testPositionClobWithUnicode in tests.jdbcapi.BlobClob4BlobTest is failing on IBM142 with "Log Record has been sent to the stream, but it cannot be applied to the store (Object null). This may cause recovery problems also."

~~DERBY-2589~~ 'Exception while trying to insert row number: XXXXX' in store/OnlineCompressTest.java

~~DERBY-3052~~ testStalePlanCheckIntervalOutOfRange(org.apache.derbyTesting.functionTests.tests.lang.StalePlansTest) fails with java.sql.SQLException: Log Record has been sent to the stream, but it cannot be applied to the store (Object null)

~~DERBY-2284~~ OnlineBackupTest1 fails with ERROR XSDB3: Container information cannot change once written: was 0, now 80

~~DERBY-3344~~ Error in testNegValueSupportedLogRecord in ugrade test - caused by EOF Exception in store in 10.3

Reference

This issue is related to:

DERBY-3607 Invalid checksum error in Derby 10.3.2.1

~~DERBY-3611~~ ERROR XSDG2: Invalid checksum on Page occurs during mass inserts into two-column bigint PK table

~~DERBY-3606~~ invalid checksum happened in Derby 10.2.2.0

~~DERBY-2677~~ OnlineCompressTest failed reporting NullPointerException, actual problem in derby.log is a page checksum error.

~~DERBY-3087~~ NPE while running the SVT MailJdbc

Issue & fix info:	Release Note Needed
Bug behavior facts:	Regression
Resolution Date:	14/Apr/08 10:17 AM

Description

« Hide

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 -------------

Description

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 -------------

Show »

All

Comments

Work Log

Change History

Subversion Commits

Sort Order:

Repository	Revision	Date	User	Message
ASF	#647091	Fri Apr 11 09:44:26 UTC 2008	kahatlen	~~DERBY-3347~~: ERROR XSDB3: Container information cannot change once written On JVMs that support the NIO API, multiple threads may perform I/O operations concurrently on the same data file. As long as these operations go through the page cache, only a single thread performs I/O on a single page at any given time. The data files can also be accessed by the container cache, which accesses space that it borrows on the first page in the file. Since these accesses don't go through the page cache, a mechanism is needed to prevent concurrent access that page. This patch makes reading and writing of the first page in a file synchronize on the container object. Since access to the borrowed space on the first page also is synchronized on the container, concurrent I/O on the first page is prevented. (On JVMs that don't support the NIO API, all page accesses synchronize on the container.)
				Files Changed
				MODIFY /db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java

Repository	Revision	Date	User	Message
ASF	#647139	Fri Apr 11 12:30:06 UTC 2008	kahatlen	~~DERBY-3347~~: ERROR XSDB3: Container information cannot change once written On JVMs that support the NIO API, use NIO consistently when accessing the data files. Mixing old style I/O and NIO has caused problems on some platforms since thread-safety is only guaranteed if all access happens through the FileChannel interface.
				Files Changed
				MODIFY /db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java MODIFY /db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/FileContainer.java MODIFY /db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java MODIFY /db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/InputStreamContainer.java

Repository	Revision	Date	User	Message
ASF	#647310	Fri Apr 11 21:07:07 UTC 2008	kahatlen	~~DERBY-3347~~: ERROR XSDB3: Container information cannot change once written (merged from trunk, revision 647091) On JVMs that support the NIO API, multiple threads may perform I/O operations concurrently on the same data file. As long as these operations go through the page cache, only a single thread performs I/O on a single page at any given time. The data files can also be accessed by the container cache, which accesses space that it borrows on the first page in the file. Since these accesses don't go through the page cache, a mechanism is needed to prevent concurrent access that page. This patch makes reading and writing of the first page in a file synchronize on the container object. Since access to the borrowed space on the first page also is synchronized on the container, concurrent I/O on the first page is prevented. (On JVMs that don't support the NIO API, all page accesses synchronize on the container.)
				Files Changed
				MODIFY /db/derby/code/branches/10.4/java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java

Repository	Revision	Date	User	Message
ASF	#647312	Fri Apr 11 21:12:42 UTC 2008	kahatlen	~~DERBY-3347~~: ERROR XSDB3: Container information cannot change once written (merged from trunk, revision 647139) On JVMs that support the NIO API, use NIO consistently when accessing the data files. Mixing old style I/O and NIO has caused problems on some platforms since thread-safety is only guaranteed if all access happens through the FileChannel interface.
				Files Changed
				MODIFY /db/derby/code/branches/10.4/java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java MODIFY /db/derby/code/branches/10.4/java/engine/org/apache/derby/impl/store/raw/data/FileContainer.java MODIFY /db/derby/code/branches/10.4/java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java MODIFY /db/derby/code/branches/10.4/java/engine/org/apache/derby/impl/store/raw/data/InputStreamContainer.java

Repository	Revision	Date	User	Message
ASF	#648210	Tue Apr 15 10:57:59 UTC 2008	kahatlen	~~DERBY-3347~~: ERROR XSDB3: Container information cannot change once written Merged fixes from trunk (revisions 647091 and 647139).
				Files Changed
				MODIFY /db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/store/raw/data/InputStreamContainer.java MODIFY /db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/store/raw/data/FileContainer.java MODIFY /db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java MODIFY /db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java