[
https://issues.apache.org/jira/browse/DERBY-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033237#comment-13033237
]
Kathey Marsden commented on DERBY-4252:
---------------------------------------
I kicked off a run with trunk and IBM 1.6 SR9. I will let it run over the
weekend and see if it pops the issue.
Booting Derby version The Apache Software Foundation - Apache Derby - 10.9.0.0 a
lpha - (1097280): instance a816c00e-012f-eac3-8c01-0000001c6ff0
on database directory C:\cygwin\home\kmarsden\repro\derby-4252\wombat with clas
s loader sun.misc.Launcher$AppClassLoader@4b304b30
Loaded from file:/C:/cygwin/svn4/trunka/jars/sane/derby.jar
java.vendor=IBM Corporation
java.runtime.version=jvmwi3260sr9-20110203_74623
java.fullversion=JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260sr9-20110203_74
623 (JIT enabled, AOT enabled)
J9VM - 20110203_074623
JIT - r9_20101028_17488ifx3
Regarding what you see in the log files with the clustered compresses at the
end, it would be interesting to see if that was the same for the passing runs.
The test basically.
1) Launches a thread that loops doing checkpoints with no pause between.
2) Loads a table with 5000 rows.
3) Deletes all the rows with a single sql statement delete from
4) calls SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE();
5) commits
6) exits normally
7) Calls a separate program to check the tables.
Looking back on this now I wonder, should everything be ok if the exit came
mid-checkpoint? I think I asked this once before and the answer was yes, but I
forget the why of it.
> 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.1.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
> Labels: derby_triage10_5_2
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
