[jira] Commented: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567653#action_12567653 ] Paul Sabatino commented on DERBY-151: - We ran into this same error when running our application over slow network connections. At first we didn't see the connection between the network and the derby error until we started to investigate interrupts. We found that if a thread was ever interrupted and you attempt a commit on that same thread you'll see this error. It seems to be linked to having the threads interrupted flag set. Here's how to test it: 1. add a Thread.interrupted(); right after the interrupt() in the attached test program d151.java. (this clears the interrupted flag) 2. Make sure the DB directory is deleted and rerun the test. It will now complete. I managed to fix our application by adjusting our network layer to clear the interrupted flag when we timed out an IO operation. That was how our issue was related to a slow network and not a local disk problem. The error message is misleading since it seems to indicate that there's a problem writing to the file, when really it just misinterpreted the interrupted flag to mean the channel was closed. You might want to fix how the interrupts are checked. > 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 > > > 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.
[jira] Updated: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Sabatino updated DERBY-151: Attachment: Derby151Test.java > 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.
[jira] Commented: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568662#action_12568662 ] Paul Sabatino commented on DERBY-151: - I thought I'd add a little more clarification to this. This error seems to only come up when the interrupt flag is set on a thread that is doing a commit that which causes a page to be written to disk. I figured this out by modifying the d151.java to take pageSize as an argument and to count how many iterations of insert and interrupt it took to fail. I then varied the pageSize and noted that the number of iterations before failure was proportional to the pageSize. So my guess was that the page was being written somewhere under the covers and causing this error. I've attached my test program. I hope this helps resolve this issue. > 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.
