[
https://issues.apache.org/jira/browse/DERBY-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3347:
----------------------------------
Attachment: WorkerThread.java
MiniStress.java
In working on another issue I hit this bug and thought I would post my program
in case it can be expanded to become a more reliable reproduction. You run it
with the number of threads as an argument and might want to bump up memory e.g.
java -Xmx512M MiniStress 50
I ran the program once to the end without error and then reran on the same db
and got the error. I haven't yet updated up to get the fix.
I ran it on my dual core Windows XP box with Sun jdk 1.6. Maybe on a box with
more CPU's it will pop the bug more reliably.
Here is the trace from the derby.log
------------ BEGIN SHUTDOWN ERROR STACK -------------
ERROR XSDG1: Page Page(1039,Container(0, 5856)) could not be written to disk,
please check if disk is full.
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:296)
at
org.apache.derby.impl.store.raw.data.CachedPage.writePage(CachedPage.java:824)
at
org.apache.derby.impl.store.raw.data.CachedPage.clean(CachedPage.java:605)
at
org.apache.derby.impl.services.cache.ConcurrentCache.cleanAndUnkeepEntry(ConcurrentCache.java:551)
at
org.apache.derby.impl.services.cache.ClockPolicy.rotateClock(ClockPolicy.java:476)
at
org.apache.derby.impl.services.cache.ClockPolicy.insertEntry(ClockPolicy.java:176)
at
org.apache.derby.impl.services.cache.ConcurrentCache.insertIntoFreeSlot(ConcurrentCache.java:208)
at
org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:284)
at
org.apache.derby.impl.store.raw.data.FileContainer.getUserPage(FileContainer.java:2412)
at
org.apache.derby.impl.store.raw.data.FileContainer.getPage(FileContainer.java:2462)
at
org.apache.derby.impl.store.raw.data.BaseContainerHandle.getPage(BaseContainerHandle.java:319)
at
org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:833)
at
org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:820)
at
org.apache.derby.impl.store.access.btree.BTreePostCommit.doShrink(BTreePostCommit.java:123)
at
org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(BTreePostCommit.java:249)
at
org.apache.derby.impl.store.raw.xact.Xact.postTermination(Xact.java:2045)
at
org.apache.derby.impl.store.raw.xact.Xact.completeCommit(Xact.java:818)
at org.apache.derby.impl.store.raw.xact.Xact.commit(Xact.java:854)
at org.apache.derby.impl.store.raw.xact.Xact.commit(Xact.java:649)
at
org.apache.derby.impl.store.access.RAMTransaction.commit(RAMTransaction.java:1964)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(GenericLanguageConnectionContext.java:1211)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(GenericLanguageConnectionContext.java:1031)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(TransactionResourceImpl.java:237)
at
org.apache.derby.impl.jdbc.EmbedConnection.commit(EmbedConnection.java:1661)
at WorkerThread.run(WorkerThread.java:24)
Caused by: java.nio.channels.ClosedChannelException
at sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:91)
at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:642)
at
org.apache.derby.impl.store.raw.data.RAFContainer4.writeFull(RAFContainer4.java:397)
at
org.apache.derby.impl.store.raw.data.RAFContainer4.writePage(RAFContainer4.java:291)
at
org.apache.derby.impl.store.raw.data.CachedPage.writePage(CachedPage.java:782)
... 23 more
============= begin nested exception, level (1) ===========
java.nio.channels.ClosedChannelException
at sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:91)
at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:642)
at
org.apache.derby.impl.store.raw.data.RAFContainer4.writeFull(RAFContainer4.java:397)
at
org.apache.derby.impl.store.raw.data.RAFContainer4.writePage(RAFContainer4.java:291)
at
org.apache.derby.impl.store.raw.data.CachedPage.writePage(CachedPage.java:782)
at
org.apache.derby.impl.store.raw.data.CachedPage.clean(CachedPage.java:605)
at
org.apache.derby.impl.services.cache.ConcurrentCache.cleanAndUnkeepEntry(ConcurrentCache.java:551)
at
org.apache.derby.impl.services.cache.ClockPolicy.rotateClock(ClockPolicy.java:476)
at
org.apache.derby.impl.services.cache.ClockPolicy.insertEntry(ClockPolicy.java:176)
at
org.apache.derby.impl.services.cache.ConcurrentCache.insertIntoFreeSlot(ConcurrentCache.java:208)
at
org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:284)
at
org.apache.derby.impl.store.raw.data.FileContainer.getUserPage(FileContainer.java:2412)
at
org.apache.derby.impl.store.raw.data.FileContainer.getPage(FileContainer.java:2462)
at
org.apache.derby.impl.store.raw.data.BaseContainerHandle.getPage(BaseContainerHandle.java:319)
at
org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:833)
at
org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:820)
at
org.apache.derby.impl.store.access.btree.BTreePostCommit.doShrink(BTreePostCommit.java:123)
at
org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(BTreePostCommit.java:249)
at
org.apache.derby.impl.store.raw.xact.Xact.postTermination(Xact.java:2045)
at
org.apache.derby.impl.store.raw.xact.Xact.completeCommit(Xact.java:818)
at org.apache.derby.impl.store.raw.xact.Xact.commit(Xact.java:854)
at org.apache.derby.impl.store.raw.xact.Xact.commit(Xact.java:649)
at
org.apache.derby.impl.store.access.RAMTransaction.commit(RAMTransaction.java:1964)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(GenericLanguageConnectionContext.java:1211)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(GenericLanguageConnectionContext.java:1031)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(TransactionResourceImpl.java:237)
at
org.apache.derby.impl.jdbc.EmbedConnection.commit(EmbedConnection.java:1661)
at WorkerThread.run(WorkerThread.java:24)
============= end nested exception, level (1) ===========
------------ END SHUTDOWN ERROR STACK -------------
> 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.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, MiniStress.java,
> WorkerThread.java
>
>
> 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.
