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

["Dag H. Wanvik (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749648#action_12749648 ] 

Dag H. Wanvik edited comment on DERBY-151 at 8/31/09 3:06 PM:
--------------------------------------------------------------

Uploading version "b" of this patch.

- Incorporated Knut's test comments.

- Changed severity to database; updated ErrorCodeTest to reflect this.
  Rationale: It seems right - I don't know that it's safe to continue
  after this kind of error, and I compared to other IO level errors in
  raw store and mostly seem to have database severity.

- Made the new Derby151Test not fail even if expected error is not
  seen. I did this to allow for possible different behavior on other
  VMs, JUnit verbose mode would instead print "Not able to test fix
  for DERBY-151: No interrupt seen".

- I added the same handling to read (even if not seen yet) as for
  write. Regressions passed modulo ErrorCodeTest, which i missed
  first time around.

- Fixed some broken Javadocs.

Ready for review. 

      was (Author: dagw):
    Uploading version "b" of this patch.

- Changed severity to database; updated ErrorCodeTest to reflect this.
  Rationale: It seems right - I don't know that it's safe to continue
  after this kind of error, and I compared to other IO level errors in
  raw store and mostly seem to have database severity.

- Made the new Derby151Test not fail even if expected error is not
  seen. I did this to allow for possible different behavior on other
  VMs, JUnit verbose mode would instead print "Not able to test fix
  for DERBY-151: No interrupt seen".

- I added the same handling to read (even if not seen yet) as for
  write. Regressions passed modulo ErrorCodeTest, which i missed
  first time around.

- Fixed some broken Javadocs.

Ready for review. 
  
> 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.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.