[
https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785085#action_12785085
]
Dag H. Wanvik edited comment on DERBY-151 at 12/3/09 1:11 AM:
--------------------------------------------------------------
Luckily this turned out to be a red herring, the shutting down does see errors
since the channel
has been closed by the interrupt, but the correct database level exception is
returned to the app (XSDG9), and
rebooting+recovery works as expected.
This will be seen on derby.log when the shutdown sees the closed channel:
ERROR XSDG9: Derby thread received an interrupt during a disk I/O operation,
please check your application for the source of the interrupt.
:
------------ BEGIN SHUTDOWN ERROR STACK -------------
ERROR XSDG1: Page Page(1,Container(0, 1120)) could not be written to disk,
please check if disk is full.
:
Caused by: java.nio.channels.ClosedChannelException
Uploading derby-151-c, which fixes a bug in the test; it asserted for the wrong
SQL state. However, assertSQLState is
a bit broken; if it can't match on the top level SQL state, it goes down the
chain to see if it can match a wrapped exception.
When that fails, it gives up and reports that it found *the innermost* wrapped
exception, whereas the application saw the outermost one,
causing me to suspect the code fix was wrong.
Running regressions.
was (Author: dagw):
Luckily this turned out to be a red herring, the shutting down does see
errors fail since the channel
has been closed, but the correct database level exception is returned to the
app (XSDG9), and
rebooting+recovery works as expected.
This will be seen on derby.log when the shutdown sees the closed channel:
ERROR XSDG9: Derby thread received an interrupt during a disk I/O operation,
please check your application for the source of the interrupt.
:
------------ BEGIN SHUTDOWN ERROR STACK -------------
ERROR XSDG1: Page Page(1,Container(0, 1120)) could not be written to disk,
please check if disk is full.
:
Caused by: java.nio.channels.ClosedChannelException
Uploading derby-151-c, which fixes a bug in the test; it asserted for the wrong
SQL state. However, assertSQLState is
a bit broken; if it can't match on the top level SQL state, it goes down the
chain to see if it can match a wrapped exception.
When that fails, it gives up and reports that it found *the innermost* wrapped
exception, whereas the application saw the outermost one,
causing me to suspect the code fix was wrong.
Running regressions.
> 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
> Assignee: Dag H. Wanvik
> Attachments: d151.java, derby-151-a.diff, derby-151-a.stat,
> derby-151-b.diff, derby-151-b.stat, derby-151-c.diff, derby-151-c.stat,
> 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.
