[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12443179 ] Knut Anders Hatlen commented on DERBY-801: ------------------------------------------
Army Brown reported an intermittent assert failure in a comment to DERBY-1976. It is probably related to this issue. The assert error is thrown when a DROP TABLE is committed. Could it be that a checkpoint is writing pages in that table's container while the container is dropped/closed? Only guessing... > I ran the JUnit suite "suites.All" against ibm142, jdk142, ibm15, jdk15, and > jdk16 on a Windows 2000 machine. The only failure I saw was an intermittent > failure in LobLengthTest on jdk15: > > There was 1 error: > 1) > testLongLobLengths(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobLengthTest) > java.sql.SQL Exception: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, > SQLERRMC: > org.apache.derby.shared.common.sanity.AssertFailure#ASSERT FAILED > Container closed > while IO operations are in progress. This should not happen.#XJ001.U > at > org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46) > at > org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:345) > at org.apache.derby.client.am.Connection.commit(Connection.java:555) > at > org.apache.derbyTesting.junit.BaseJDBCTestCase.commit(BaseJDBCTestCase.java:159) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.LobLengthTest.tearDown(LobLengthTest.java:87) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: > SQLCODE: -1, > SQLSTATE: XJ001, SQLERRMC: > org.apache.derby.shared.common.sanity.AssertFailure#ASSERT > FAILED Container closed while IO operations are in progress. This should > not happen.#XJ001.U > at > org.apache.derby.client.am.Connection.completeSqlca(Connection.java:1920) > at > org.apache.derby.client.net.NetConnectionReply.parseRDBCMMreply(NetConnectionReply.java:215) > at > org.apache.derby.client.net.NetConnectionReply.readLocalCommit(NetConnectionReply.java:147) > at > org.apache.derby.client.net.ConnectionReply.readLocalCommit(ConnectionReply.java:43) > at > org.apache.derby.client.net.NetConnection.readLocalCommit_(NetConnection.java:1574) > at > org.apache.derby.client.am.Connection.readCommit(Connection.java:639) > at > org.apache.derby.client.am.Connection.flowCommit(Connection.java:588) > at org.apache.derby.client.am.Connection.commit(Connection.java:551) > ... 33 more > Allow parallel access to data files. > ------------------------------------ > > Key: DERBY-801 > URL: http://issues.apache.org/jira/browse/DERBY-801 > Project: Derby > Issue Type: Improvement > Components: Performance, Store > Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1 > Environment: Any > Reporter: Øystein Grøvlen > Assigned To: Anders Morken > Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, > DERBY-801-v4.patch, NIO-RAFContainer-v1.patch > > > Derby currently serializes accesses to a data file. For example, the > implementation of RAFContainer.readPage is as follows: > synchronized (this) { // 'this' is a FileContainer, i.e. a file object > fileData.seek(pageOffset); // fileData is a RandomAccessFile > fileData.readFully(pageData, 0, pageSize); > } > I have experiemented with a patch where I have introduced several file > descriptors (RandomAccessFile objects) per RAFContainer. These are > used for reading. The principle is that when all readers are busy, a > readPage request will create a new reader. (There is a maximum number > of readers.) With this patch, throughput was improved by 50% on > linux. For more discussion on this, see > http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html > The challenge with the suggested approach is to make a mechanism to > limit the number of open file descpriptors. Mike Matrigali has > suggested to use the existing CacheManager infrastructure for this > purpose. For a discussion on that, see: > http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
