You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Barnet Wagman (JIRA)" <de...@db.apache.org> on 2005/02/21 08:08:49 UTC
[jira] Created: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Thread termination -> XSDG after operation is 'complete'
--------------------------------------------------------
Key: DERBY-151
URL: http://issues.apache.org/jira/browse/DERBY-151
Project: Derby
Type: Bug
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Kommentiert: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by "Jörg von Frantzius (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-151?page=comments#action_12329353 ]
Jörg von Frantzius commented on DERBY-151:
------------------------------------------
Trying to catch ClosedByInterruptException in RAFContainer would give a dependency on Java 1.4. Not sure whether that is wanted, and I'm having a bit of a hard time to get build.xml compile it (there is 1.4 classes being used in impl.io without problems?!)
> 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
> Attachments: 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.
-
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
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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
> 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.
[jira] Resolved: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik resolved DERBY-151.
---------------------------------
Resolution: Fixed
Fix Version/s: 10.6.0.0
Issue & fix info: [High Value Fix, Repro attached] (was: [Repro attached, Patch Available, High Value Fix])
Committed derby-151-followup as svn 886963, resolving.
> 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
> Fix For: 10.6.0.0
>
> 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-151-followup.diff, 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] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Paul Sabatino (JIRA)" <ji...@apache.org>.
[ 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'
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566268#action_12566268 ]
Kathey Marsden commented on DERBY-151:
--------------------------------------
I am thinking of closing this issue CannotReproduce. Please let me know if you have any objections.
It can be reopened if we get a repro.
> 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: 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'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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-a.stat
derby-151-a.diff
Uploading a patch that catches the ClosedByInterruptException and
throws a more meaningful error message as suggested above.
I added a test to the store regression suite and ran it successfully on Windows Vista and OpenSolaris.
> 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-151-a.diff, derby-151-a.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.
[jira] Issue Comment Edited: (DERBY-151) Thread termination -> XSDG
after operation is 'complete'
Posted by "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.
[jira] Assigned: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik reassigned DERBY-151:
-----------------------------------
Assignee: Dag H. Wanvik
> 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.
[jira] Kommentiert: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by "Jörg von Frantzius (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-151?page=comments#action_12329367 ]
Jörg von Frantzius commented on DERBY-151:
------------------------------------------
For any Eclipse-plugin, Swing or GUI programmers in general seeing this bug: writing to the embedded DB from the UI thread is a bad idea, as that thread gets interrupted very frequently. Moving write operations into their own thread solved the problem for stupid me.
Cheers!
> 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
> Attachments: 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.
-
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
[jira] Commented: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-151?page=comments#action_12329341 ]
Suresh Thalamati commented on DERBY-151:
----------------------------------------
Real cause for the error(ERROR XSDG1: Page Page(7,Container(0, 1088)) could not be written to disk, please check if disk is full. ) is :
java.nio.channels.ClosedByInterruptException
at java.nio.channels.spi.AbstractInterruptibleChannel.end(Unknown Source)
at sun.nio.ch.FileChannelImpl.force(Unknown Source)
at org.apache.derby.impl.io.DirRandomAccessFile4.sync(Unknown Source)
at org.apache.derby.impl.store.raw.data.RAFContainer.writePage(Unknown Source)
at org.apache.derby.impl.store.raw.data.CachedPage.writePage(Unknown Source)
............
file sync is being interrupted , because user is interrupting the thread that is doing the database activity.
May the Interrupt exception should be caught .. and reissue the sync if possible and also generate better error
if it can not be synced even on a second attempt . Discussion about transaction log on the user list:
http://www.mail-archive.com/derby-user@db.apache.org/msg01577.html
> 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
> Attachments: 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.
-
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
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-151:
-------------------------------------
Attachment: d151.java
Attached is a repro.
The good news is that from 10.3 the java.nio.channels.ClosedByInterruptException is linked to the SQLException, so printStackTrace() will show that it's the underlying cause. But the SQLException still says "please check if disk is full".
Another piece of good news: In an earlier comment, Suresh suggested that we could catch ClosedByInterruptException and use that to reissue the sync() and/or give a better error message. The suggestion was rejected because it would introduce a dependency on Java 1.4 in RAFContainer. From 10.3 we have RAFContainer4 which *is* depending on Java 1.4, so that shouldn't stop us anymore.
> 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'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-151:
--------------------------------
Attachment: (was: derby-151-a.stat)
> 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-151-a.diff, derby-151-a.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.
[jira] Commented: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by "Jörg von Frantzius (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-151?page=comments#action_12327827 ]
Jörg von Frantzius commented on DERBY-151:
------------------------------------------
I might add that the disk is not full, and in contrast to the original poster, it doesn't seem to be a threading issue. As the stacktrace shows, it is the thread that issued the UPDATE statement that gets the exception.
I've got the following non-default page cache settings:
derby.storage.pageCacheSize = 320
derby.storage.pageSize = 16384
> 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
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-151:
--------------------------------
Attachment: (was: derby-151-followup.diff)
> 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.
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-151:
--------------------------------
Attachment: (was: derby-151-b.diff)
> 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.
[jira] Commented: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "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=12785045#action_12785045 ]
Dag H. Wanvik commented on DERBY-151:
-------------------------------------
Hmm, seems there is a problem with patch version b, changing the
severity to database makes the database try to shut down, which
doesn't work as long as the interrupt flag is set, I guess, since shutting down attempts more writing operations.
> 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.
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-151:
--------------------------------
Attachment: (was: derby-151-c.diff)
> 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.
[jira] Updated: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by "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
[jira] Updated: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by "Jörg von Frantzius (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-151?page=all ]
Jörg von Frantzius updated DERBY-151:
-------------------------------------
Attachment: .log
Alright, I didn't think of that! Here's the log (I think the last shutdown can be ignored).
> 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
> Attachments: .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.
-
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
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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-b.diff
> 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.
[jira] Commented: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Paul Sabatino (JIRA)" <ji...@apache.org>.
[ 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] Commented: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "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=12785367#action_12785367 ]
Dag H. Wanvik commented on DERBY-151:
-------------------------------------
Committed patch derby-151-c as svn 886831.
> 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.
[jira] Commented: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-151?page=comments#action_12329329 ]
Suresh Thalamati commented on DERBY-151:
----------------------------------------
derby.log occasional has more information than the above stack mentioned. In most cases , some sort of IO exception has
to happen for the above error to occur, all the exception are nested inside the SQL Exception. If the derby.log file is still around ,
please attach it to the jira.
> 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
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-151:
--------------------------------
Attachment: (was: derby-151-a.diff)
> 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-151-a.diff, derby-151-a.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.
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-151:
--------------------------------
Attachment: (was: derby-151-c.stat)
> 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.
[jira] Commented: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-151?page=comments#action_12378722 ]
Kathey Marsden commented on DERBY-151:
--------------------------------------
I was wondering if anyone could provide some expanded information on this issue. I am really not all that familiar with running Derby in eclipse and have
some probably very basic questions which are:
1) I was wondering if anyone had some information on accessing Derby
from within eclipse and avoiding ClosedByInterruptException as
described in DERBY-151. Do you always need to launch a separate thread for any Derby access when running in eclipse?
2) If the answer to #1 is "Yes", is there a Derby solution to this problem that is possible or is it strictly a user issue, for example, if the retry was implemented would that eliminate the requirement to access Derby in a separate thread?
3) Are there any similar issues with interuption when accessing with the client driver?
4) Is using embedded server ok with eclipse? The plugins doc seems to
imply that you should always use network server and access with Derby
client.
http://db.apache.org/derby/integrate/plugin_help/start_toc.html
Thanks!
> 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
> Attachments: 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.
-
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
[jira] Commented: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Trejkaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607454#action_12607454 ]
Trejkaz commented on DERBY-151:
-------------------------------
I've been wrestling with this issue too. I can't reproduce it reliably in the live system but it happens often enough to be an annoyance, and our unit tests cause it to occur much more often.
In our case it's occurring on one of our own threads so moving database work off the EDT can't help.
Closing and reopening the connection doesn't make it work again, we have to do a shutdown and start it again, and then it appears to work (until the problem occurs again.) When running the real application when there is a connection pool in effect, this becomes very hard to do.
> 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] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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-a.stat
derby-151-a.diff
> 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-151-a.diff, derby-151-a.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.
[jira] Commented: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Paul Sabatino (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-151:
---------------------------------
Derby Categories: [High Value Fix]
> 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] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-151:
-------------------------------------
Issue & fix info: [High Value Fix, Repro attached] (was: [High Value Fix])
Bug behavior facts: [Seen in production]
> 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] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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-b.stat
derby-151-b.diff
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
> 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.
[jira] Commented: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by "Jörg von Frantzius (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-151?page=comments#action_12327401 ]
Jörg von Frantzius commented on DERBY-151:
------------------------------------------
I'm seeing the same, on Windows XP (Derby 10.1.1.0). Here's my stacktrace:
[main][14.09.2005 16:37:36,115] DEBUG Request.java:66 - INSERT INTO KUENSTLER (LEBENSDATEN,LITERATUR,GEBURTS_ORT,KUENSTLER_NAME,LEGACY_ID,"NAME",GEBURTSDATUM,LAST_MODIFICATION,ERGAENZUNGEN,ADRESSE,GESCHLECHT,STERBEDATUM,VORNAME,BIOGRAPHIE,ID) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
ERROR XSDG1: Page Page(7,Container(0, 1088)) could not be written to disk, please check if disk is full.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.store.raw.data.CachedPage.writePage(Unknown Source)
at org.apache.derby.impl.store.raw.data.CachedPage.createIdentity(Unknown Source)
at org.apache.derby.impl.services.cache.CachedItem.takeOnIdentity(Unknown Source)
at org.apache.derby.impl.services.cache.Clock.addEntry(Unknown Source)
at org.apache.derby.impl.services.cache.Clock.create(Unknown Source)
at org.apache.derby.impl.store.raw.data.FileContainer.initPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.FileContainer.newPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.BaseContainer.addPage(Unknown Source)
at org.apache.derby.impl.store.raw.data.BaseContainerHandle.addPage(Unknown Source)
at org.apache.derby.impl.store.access.heap.HeapController.doInsert(Unknown Source)
at org.apache.derby.impl.store.access.heap.HeapController.insertAndFetchLocation(Unknown Source)
at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown Source)
at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown Source)
at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)
> 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
[jira] Updated: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by "Andrew McIntyre (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-151?page=all ]
Andrew McIntyre updated DERBY-151:
----------------------------------
Attachment: (was: .log)
> 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
> Attachments: 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.
-
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
[jira] Issue Comment Edited: (DERBY-151) Thread termination -> XSDG
after operation is 'complete'
Posted by "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=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.
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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-followup.diff
> 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-151-followup.diff, 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] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-151:
--------------------------------
Issue & fix info: [High Value Fix, Patch Available, Repro attached] (was: [Repro attached, High Value Fix])
> 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-151-a.diff, derby-151-a.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.
Re: [jira] Updated: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by Andrew McIntyre <mc...@gmail.com>.
On Sep 14, 2005, at 11:21 AM, Jörg von Frantzius (JIRA) wrote:
> Sorry, that was the wrong log! Could someone please delete it? It
> seems I can't.
> Here's the correct one (derby.log)
I've deleted the first log file.
andrew
[jira] Updated: (DERBY-151) Thread termination -> XSDG after operation is 'complete'
Posted by "Jörg von Frantzius (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-151?page=all ]
Jörg von Frantzius updated DERBY-151:
-------------------------------------
Attachment: derby.log
Sorry, that was the wrong log! Could someone please delete it? It seems I can't.
Here's the correct one (derby.log)
> 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
> Attachments: .log, 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.
-
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
[jira] Updated: (DERBY-151) Thread termination -> XSDG after
operation is 'complete'
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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-followup.diff
Uploading an improved test (derby-151-followup.diff), which also tests using the client driver.
> 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-151-followup.diff, 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'
Posted by "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=12783205#action_12783205 ]
Dag H. Wanvik commented on DERBY-151:
-------------------------------------
Picking this up again; I haven't received any more comments on this, and it seems a net improvement
to me even if it may not be a panacea. I intend to commit this soon, unless anybody has any misgivings.
> 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.