[
https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746393#action_12746393
]
Dag H. Wanvik commented on DERBY-151:
-------------------------------------
My observation is really unrelated to the RAFContainer4 situation; if I move
the call of Thread.currentThread().interrupt() in d151.java
to *after* the first executeUpdate, this doesn't happen, because all relevant
classes have been read by the classloader.
See DERBY-1338 for details.
So really it's just another manifestation of the fact that interrupting a Derby
thread is not really healthy.
I think we should just catch the ClosedByInterruptException and create a more
explanatory error message, e.g maybe thus:
Exception in thread "main" java.sql.SQLException: Derby thread received an
interrupt during a write operation, please check your application.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:278)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:398)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2204)
at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1323)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1675)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:302)
at d151.main(d151.java:18)
Caused by: java.sql.SQLException: Java exception: ':
java.nio.channels.ClosedByInterruptException'.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:299)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403)
... 8 more
Caused by: java.nio.channels.ClosedByInterruptException
at
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:184)
at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:656)
at
org.apache.derby.impl.store.raw.data.RAFContainer4.writeFull(RAFContainer4.java:496)
at
org.apache.derby.impl.store.raw.data.RAFContainer4.writePage0(RAFContainer4.java:346)
at
org.apache.derby.impl.store.raw.data.RAFContainer4.writePage(RAFContainer4.java:291)
at
org.apache.derby.impl.store.raw.data.CachedPage.writePage(CachedPage.java:787)
at
org.apache.derby.impl.store.raw.data.CachedPage.createIdentity(CachedPage.java:305)
at
org.apache.derby.impl.services.cache.ConcurrentCache.create(ConcurrentCache.java:388)
at
org.apache.derby.impl.store.raw.data.FileContainer.initPage(FileContainer.java:2336)
at
org.apache.derby.impl.store.raw.data.FileContainer.newPage(FileContainer.java:1800)
at
org.apache.derby.impl.store.raw.data.BaseContainer.addPage(BaseContainer.java:314)
at
org.apache.derby.impl.store.raw.data.BaseContainerHandle.addPage(BaseContainerHandle.java:183)
at
org.apache.derby.impl.store.access.heap.HeapController.doInsert(HeapController.java:302)
at
org.apache.derby.impl.store.access.heap.HeapController.insertAndFetchLocation(HeapController.java:599)
at
org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(RowChangerImpl.java:452)
at
org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1022)
at
org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:495)
at
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:416)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:297)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235)
> Thread termination -> XSDG after operation is 'complete'
> --------------------------------------------------------
>
> Key: DERBY-151
> URL: https://issues.apache.org/jira/browse/DERBY-151
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.0.2.1
> Environment: Linux kernel 2.4.21-243-athlon (SuSE 9.0)
> Reporter: Barnet Wagman
> Attachments: d151.java, derby.log, Derby151Test.java
>
>
> I've encountered what appears to be a bug related to threading. After an
> INSERT operation, if the invoking thread terminates too quickly, Derby throws
> an XSDG.
> The bug is a bit difficult to isolate but it occurs consistently in the
> following situation (with a particular database and an operation of a
> particular size):
> Derby is running in embedded mode with autocommit on.
> The application performs an INPUT operation from a thread that is not the
> main thread. The INPUT is issued using a PreparedStatement. The INPUT adds
> ~ 256 records of six fields each. (Note that INSERTs of this size seem to
> work fine in other contexts.)
>
> The preparedStatement.executeUpdate() seems to excute successfully; at least
> it returns without throwing an exception.
> The thread that invoked the INPUT operation then terminates (but NOT the
> application). The next INPUT operation then results in an
> "ERROR XSDG1: Page Page(7,Container(0, 1344)) could not be written to disk,
> please check if disk is full."
> The disk is definitely not full.
> HOWEVER, if I put the calling thread to sleep for a second before it exits,
> the problem does not occur.
> I'm not quite sure what to make of this. I was under the impression that
> most of Derby's activity occurs in the application's threads. Could Derby be
> creating a child thread from in the application thread, which dies when the
> parent thread terminates?
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
