db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5312) InterruptResilienceTest failed with ERROR 40XD1: Container was opened in read-only mode.
Date Tue, 12 Jul 2011 22:16:59 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064193#comment-13064193

Mike Matrigali commented on DERBY-5312:

the patch looks fine to me, the work need not be done for a reopen.

But, isn't the real problem that there is some uncoordinated activity that should be coordinated.
 Some thread is actively doing
work on the filecontainer because it thinks it is open, but the code is in the middle of reopening
it.  Is there going be some
other problem with the rest of the work in the reopen and the competing thread or is that
handled somehow else.  I did not 
follow all the work in this area so if this is meant to be handled somehow else, good.  maybe
just another comment in your
change explaining why it is ok for use()  to complete while the file is being reopened would
help.  I see there is a comment
about deadlock on synchonization later so that is likely an issue.

Is closeContainer() access to fileData with no sync a problem?

Do you think there is any similar problem with isStub as canUpdate?

I don't know if it is possible but is it possible the only work that needs to be done on a
reopen is:
fileData = file.getRandomAccessFile(canUpdate ? "rw" : "r");
    or does the closing exception lose isStub, file, and/or fileName?

> InterruptResilienceTest failed with ERROR 40XD1: Container was opened in read-only mode.
> ----------------------------------------------------------------------------------------
>                 Key: DERBY-5312
>                 URL: https://issues.apache.org/jira/browse/DERBY-5312
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:
>         Environment: Oracle Solaris 11 Express snv_151a X86
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode)
>            Reporter: Knut Anders Hatlen
>            Assignee: Dag H. Wanvik
>         Attachments: derby-5312a.diff, derby.log, error-stacktrace.out
> WorkerThread failed with this exception:
> ERROR 40XD1: Container was opened in read-only mode.
> 	at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:276)
> 	at org.apache.derby.impl.store.raw.data.BaseContainer.use(BaseContainer.java:562)
> 	at org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(BaseContainerHandle.java:834)
> 	at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:773)
> 	at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:589)
> 	at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java:1316)
> 	at org.apache.derby.impl.store.access.btree.OpenBTree.init(OpenBTree.java:382)
> 	at org.apache.derby.impl.store.access.btree.BTreeController.init(BTreeController.java:1225)
> 	at org.apache.derby.impl.store.access.btree.index.B2IController.init(B2IController.java:140)
> 	at org.apache.derby.impl.store.access.btree.index.B2I.open(B2I.java:824)
> 	at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:476)
> 	at org.apache.derby.impl.store.access.RAMTransaction.openCompiledConglomerate(RAMTransaction.java:1293)
> 	at org.apache.derby.impl.sql.execute.IndexChanger.openIndexCC(IndexChanger.java:507)
> 	at org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(IndexChanger.java:438)
> 	at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(IndexChanger.java:383)
> 	at org.apache.derby.impl.sql.execute.IndexChanger.insert(IndexChanger.java:590)
> 	at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(IndexSetChanger.java:268)
> 	at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(RowChangerImpl.java:453)
> 	at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:999)
> 	at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:519)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1686)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:308)
> 	at org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest$WorkerThread.run(InterruptResilienceTest.java:449)
> I was testing a patch for DERBY-4620 (estimate-sizes.diff), but I think the failure isn't
related to those changes.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message