db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Date Thu, 03 Dec 2009 00:43:20 GMT

     [ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dag H. Wanvik updated DERBY-151:
--------------------------------

    Attachment: derby-151-c.stat
                derby-151-c.diff

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.


Mime
View raw message