[
https://issues.apache.org/jira/browse/DERBY-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587948#action_12587948
]
Knut Anders Hatlen commented on DERBY-3347:
-------------------------------------------
Thanks again, Dag. Patch 1b has been committed with revision 647139.
I agree that the code and comments in this area would benefit from an overhaul.
The abstractions in the original code were obviously chosen to match the
RandomAccessFile way of accessing the data files, and the NIO code doesn't fit
very well into that model. Some of the comments added as part of DERBY-801 also
mention that a restructuring of the interfaces would be beneficial.
Regarding the comment in StorageRandomAccessFile, I think it's correct,
actually. The only parts of a StorageRandomAccessFile that need to be thread
safe, are the methods on the FileChannel object returned by the getChannel()
method. However, the SRAF interface doesn't know anything about FileChannel or
getChannel(), it's just RAFContainer4 that knows that some SRAF implementations
are subclasses of java.io.RAF, and therefore manages to retrieve FileChannels
from them. None of the SRAF methods are ever called concurrently on the same
object.
> 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.5.0.0
>
> Attachments: d3347-1a.diff, d3347-1a.stat, d3347-1b.diff,
> 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.
