[
https://issues.apache.org/jira/browse/DERBY-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725247#action_12725247
]
Kathey Marsden commented on DERBY-4252:
---------------------------------------
The frequency declined significantly after the fix for DERBY-4239, before
that fix it would occur after about 12 iterations with IBM 1.6instead of 200.
Also when I came up with the Windows repro for DERBY-4239, I only saw the
DERBY-4239 error on the Sun JVM. On IBM 1.6 I would hit this EOFException
first. See:
https://issues.apache.org/jira/browse/DERBY-4239?focusedCommentId=12712720&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12712720
Thank you for looking at this issue. When I asked Mike whether I should try
to get a more reliable reproduction, he suggested we first analyze the log from
the corrupted database. Mike posted some tips for doing this at:
https://issues.apache.org/jira/browse/DERBY-4239?focusedCommentId=12711832&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12711832
Perhaps he has some more specific suggestions as to what to look for here.
> intermittent corruption./java.io.EOFException in RandomAccessFile.readInt()
> on boot after compress with background checkpoint
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4252
> URL: https://issues.apache.org/jira/browse/DERBY-4252
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.6.0.0
> Environment: Windows XP dualcore.
> java version "1.6.0"
> Java(TM) SE Runtime Environment (build pwi3260sr4-20090219_01(SR4))
> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32
> jvmwi3260-20090215_29883 (JIT enabled, AOT enabled)
> J9VM - 20090215_029883_lHdSMr
> JIT - r9_20090213_2028
> GC - 20090213_AA)
> JCL - 20090218_01
> Also tried with the latest development SR5 version and it reproduces.
> Reporter: Kathey Marsden
> Priority: Critical
> Attachments: corrupt_database_with_logs.zip,
> reproBackgroundCheckpoint.zip
>
>
> The attached reproduction reproBackgroundCheckpoint.zip occasionally results
> in an EOF exception on boot with IBM 1.6 (about 1 out of 200 runs) even
> after the fix for DERBY-4239. The program inserts into /deletes some data
> from a table and runs compress, and as a daemon thread that loops
> checkpoints. I have not seen it with the Sun JVM.
> Before the fix for DERBY-4239, this issue was much more frequent. Sometimes
> you would get the DERBY-4239 trace and sometimes this one. After the fix,
> this issue remains. Mike thought it looked like a different bug and asked
> that we file a separate issue.
> This is the trace:
> java.io.EOFException
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:739)
> at java.io.RandomAccessFile.readLong(RandomAccessFile.java:772)
> at
> org.apache.derby.impl.store.raw.log.Scan.getNextRecordForward(Unknown Source)
> at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Unknown
> Source)
> at org.apache.derby.impl.store.raw.log.FileLogger.redo(Unknown Source)
> at org.apache.derby.impl.store.raw.log.LogToFile.recover(Unknown Source)
> at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source)
> at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown
> Source)
> at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
> at
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown
> Source)
> at org.apache.derby.impl.store.access.RAMAccessManager.boot(Unknown
> Source)
> at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown
> Source)
> at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
> at
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown
> Source)
> at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source)
> at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source)
> at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown
> Source)
> at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown
> Source)
> at
> org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
> at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source)
> at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
> at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
> at java.sql.DriverManager.getConnection(DriverManager.java:316)
> at java.sql.DriverManager.getConnection(DriverManager.java:273)
> at CheckTables.main(CheckTables.java:8)
> To reproduce, compile the java programs and run reprobckchkpt.ksh. You may
> want to increase the number of iterations and let it run overnight to see the
> failure or back out the fix for DERBY-4239 to see it happen quicker.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
