[jira] Updated: (DERBY-151) Thread termination -> XSDG after operation is 'complete'

["Mike Matrigali (JIRA)" <de...@db.apache.org>]

     [ http://issues.apache.org/jira/browse/DERBY-151?page=all ]

Mike Matrigali updated DERBY-151:
---------------------------------

      Component: Store
    Description: 
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





  was:
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






Without some sort of reproducible case, don't think this issue will be addressed.  Also always include all the 
stack trace information from derby.log whenever possible.  

My best guess is that somehow a thread interrupt is being sent to the thread issuing the I/O, possibly the interrupt
is even being posted to the thread before the execute statement is being called?  

To answer the question, the I/O described above could be issued either by the thread doing the insert , or it could
be issued by a background thread executing a checkpoint.  The stack track would tell which.  

> Thread termination -> XSDG after operation is 'complete'
> --------------------------------------------------------
>
>          Key: DERBY-151
>          URL: http://issues.apache.org/jira/browse/DERBY-151
>      Project: Derby
>         Type: Bug
>   Components: Store
>     Versions: 10.0.2.1
>  Environment: Linux kernel 2.4.21-243-athlon (SuSE 9.0)
>     Reporter: Barnet Wagman

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