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 20:42:59 GMT

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

Mike Matrigali commented on DERBY-5312:

It looks like there is little synchronization on that variable and access is shared across
multiple files, as noted below.
While very short it does seem possible for a change to happen to canUpdate after it is checked,
and JIT probably can't
opt it out as it is a shared variable.  Just to check for a JIT bug it may help to rewrite
as something like:

if (!(tmp_canUpdate = canUpdate))
        print both tmp and canUpdate

Maybe a bit more instrumentation might help.  Maybe the stack of the call.  Or at least for
your test I think if you throw an
assert then the new error reporting stuff will print stacks of every thread.  It may not work
though as we are talking about
a few instructions while the stack dumps are likely 1000's or more.   Has the feel of one
thread opening a shared
container and not properly coordinating with someone that is closing it.  Given the test,
is it likely someone is incorrectly
closing the container?

Is this test likely flooding the container cache?

There is at least competition on this resource between user thread and store background daemon
either doing checkpoint
or post commit work.  If the test has multiple threads than add that also.

BaseContainer.java:             if (forUpdate && !canUpdate())
BaseContainer.java:     protected abstract boolean canUpdate();
FileContainer.java:     protected boolean canUpdate;        // can I be written
FileContainer.java:             canUpdate = false;
FileContainer.java:     protected boolean canUpdate() {
FileContainer.java:             return canUpdate;
InputStreamContainer.java:              canUpdate = false;
RAFContainer.java:             canUpdate = true;
RAFContainer.java:             canUpdate = false;
RAFContainer.java:                     canUpdate = true;
RAFContainer.java:                 fileData = file.getRandomAccessFile(canUpdate
 ? "rw" : "r");
RAFContainer.java:                             stub.getRandomAccessFile(canUpdat
e ? "rw" : "r");

> 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.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