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 "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2006/08/19 20:57:13 UTC
[jira] Created: (DERBY-1732) The langauge and store systems treat a
JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
The langauge and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
----------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-1732
URL: http://issues.apache.org/jira/browse/DERBY-1732
Project: Derby
Issue Type: Bug
Components: SQL, Store
Reporter: Daniel John Debrunner
Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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] Reopened: (DERBY-1732) The language and store systems treat
a JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Sunitha Kambhampati (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Sunitha Kambhampati reopened DERBY-1732:
----------------------------------------
Assignee: Sunitha Kambhampati (was: Rajesh Kartha)
Reopen to correct the assign to field.
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.1.2.1, 10.3.0.0, 10.1.3.1, 10.2.2.0
> Reporter: Daniel John Debrunner
> Assigned To: Sunitha Kambhampati
> Fix For: 10.3.0.0, 10.2.2.0
>
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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-1732) The language and store systems treat a
JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Sunitha Kambhampati updated DERBY-1732:
---------------------------------------
Attachment: derby1732.diff.txt
derby1732.stat.txt
Notes:
On a JVM error, the cleanup at the store layer treats it as a session_severity error --
see RAMTransactionContext.cleanupOnError(), XactContext.cleanupOnError().
the transaction is aborted,destroyed, transaction context is pop'd from the context stack.
At the language side however:
GenericStatementContext (SC) will treat a java error to be similar to STATEMENT_SEVERITY.
GenericLanguageConnectionContex (LCC) will treat a java error to be of TRANSACTION_SEVERITY.
If an exception occurs, the contextManager.cleanupOnError is called to ensure corrective action can be taken. The context manager will unwind the contexts during cleanup in the reverse order they were placed in the global stack.
In ContextManager.cleanupOnError(),
-- A non StandardException (a jvm error) gets mapped to NO_APPLICABLE_SEVERITY here:
int errorSeverity = error instanceof StandardException ?
((StandardException) error).getSeverity() :
ExceptionSeverity.NO_APPLICABLE_SEVERITY;
-- Next, we walk down the stack calling cleanup on each context as long as if we reached the lastHandler or if we have reached end of stack.
So if a given context is the last handler for an error of some severity, then we stop there and do not call cleanup on the context's below it.
The derby1707 repro debugging shows that in this case - at prepare time for the statement, a NPE is thrown from GenericStatement.prepMinion. In the context stack,store contexts are first cleaned up and then the SC cleanup is called. Note: LCC is below in the stack and LCC cleanup does not get called since the SC.isLastHandler returns true.
Issue:
-- isLastHandler for GenericStatement is not right. JVM errors severity gets mapped to NO_APPLICABLE_SEVERITY in
ContextManager.cleanupOnError(). Thus on cleanup, for JVM error SC.isLastHandler can return true for some cases(when rollbackParentContext is false, and inUse is true). This is incorrect because for JVM errors, it is necessary to let the outer contexts know and take necessary corrective action.
This patch makes the following changes:
1. Make change to GenericStatementContext.isLastHandler() so it will return false for JVM errors thus allowing the outer contexts to take corrective action.
2. Store transaction context treats JVM errors as session severity. To ensure consistency, map severity for non StandardException instances to be SESSION_SEVERITY in GenericLanguageContext, and GenericStatementContext.
There is an existing DERBY-1528 which also results in a npe and then the raw store protocol violation error. With this change, if you run the repro (repro1528_npe), instead of a raw store protocol violation error, you will get a java.sql.SQLException 'No current exception'
Ran derbyall on ibm142/linux ok with 2 expected failures unrelated to this change. (NSInSameJVM and blobclob4BLOB)
I have been using the derby1707 repro without the fix for this jira for testing purposes. Are there any suggestions on how best to add a test for this case. One way is to simulate a java error using debug flags but I dont like that approach. Suggestions welcome. I can make the yet-to-be-fixed derby1528 repro as a test,but that will no longer test this fix when we eventually fix derby-1528.
Please take a look at this patch. I am new to this area, so would appreciate more eyes on this patch. Thanks.
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Reporter: Daniel John Debrunner
> Assigned To: Sunitha Kambhampati
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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] Closed: (DERBY-1732) The language and store systems treat a
JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Rick Hillegas closed DERBY-1732.
--------------------------------
Resolution: Fixed
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.1.2.1, 10.3.0.0, 10.1.3.1, 10.2.2.0
> Reporter: Daniel John Debrunner
> Assigned To: Rajesh Kartha
> Fix For: 10.2.2.0, 10.3.0.0
>
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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] Reopened: (DERBY-1732) The language and store systems treat
a JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Rick Hillegas reopened DERBY-1732:
----------------------------------
Assignee: Rajesh Kartha (was: Sunitha Kambhampati)
Re-opening to record porting to 10.2 branch
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.1.2.1, 10.3.0.0, 10.1.3.1, 10.2.2.0
> Reporter: Daniel John Debrunner
> Assigned To: Rajesh Kartha
> Fix For: 10.3.0.0, 10.2.2.0
>
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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] Resolved: (DERBY-1732) The language and store systems treat
a JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Sunitha Kambhampati resolved DERBY-1732.
----------------------------------------
Resolution: Fixed
Verified fix in trunk. Thanks Dan for the review and commit.
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0, 10.2.1.6, 10.2.2.0, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: Sunitha Kambhampati
> Fix For: 10.3.0.0
>
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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] Closed: (DERBY-1732) The language and store systems treat a
JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Sunitha Kambhampati closed DERBY-1732.
--------------------------------------
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0, 10.2.1.6, 10.2.2.0, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: Sunitha Kambhampati
> Fix For: 10.3.0.0
>
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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-1732) The language and store systems treat a
JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Rick Hillegas updated DERBY-1732:
---------------------------------
Fix Version/s: 10.2.2.0
Ported to 10.2 branch at subversion revision 480074.
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.1.2.1, 10.3.0.0, 10.1.3.1, 10.2.2.0
> Reporter: Daniel John Debrunner
> Assigned To: Rajesh Kartha
> Fix For: 10.3.0.0, 10.2.2.0
>
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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] Closed: (DERBY-1732) The language and store systems treat a
JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Sunitha Kambhampati (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Sunitha Kambhampati closed DERBY-1732.
--------------------------------------
Resolution: Fixed
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.1.2.1, 10.3.0.0, 10.1.3.1, 10.2.2.0
> Reporter: Daniel John Debrunner
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.2.0, 10.3.0.0
>
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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-1732) The language and store systems treat
a JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=comments#action_12438464 ]
Daniel John Debrunner commented on DERBY-1732:
----------------------------------------------
Patch looks good, I don't think there needs to be a test here. If the code had been correct in the first place there would never have been a test case because it is not functionality that is being developed.
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.5, 10.1.2.1, 10.1.3.0, 10.3.0.0, 10.1.3.1, 10.2.2.0
> Reporter: Daniel John Debrunner
> Assigned To: Sunitha Kambhampati
> Fix For: 10.3.0.0
>
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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] Assigned: (DERBY-1732) The language and store systems treat
a JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Sunitha Kambhampati reassigned DERBY-1732:
------------------------------------------
Assignee: Sunitha Kambhampati
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Reporter: Daniel John Debrunner
> Assigned To: Sunitha Kambhampati
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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-1732) The language and store systems treat a
JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Daniel John Debrunner updated DERBY-1732:
-----------------------------------------
Derby Info: (was: [Patch Available])
Patch Committed revision 453395 - Thanks Sunitha.
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0, 10.2.1.6, 10.2.2.0, 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: Sunitha Kambhampati
> Fix For: 10.3.0.0
>
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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-1732) The language and store systems treat a
JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Sunitha Kambhampati updated DERBY-1732:
---------------------------------------
Fix Version/s: 10.3.0.0
Affects Version/s: 10.1.3.1
10.1.3.0
10.1.2.1
10.1.1.0
10.0.2.1
10.0.2.0
10.2.1.5
10.2.2.0
10.3.0.0
Derby Info: [Patch Available]
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.5, 10.1.2.1, 10.1.3.0, 10.3.0.0, 10.1.3.1, 10.2.2.0
> Reporter: Daniel John Debrunner
> Assigned To: Sunitha Kambhampati
> Fix For: 10.3.0.0
>
> Attachments: derby1732.diff.txt, derby1732.stat.txt
>
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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-1732) The language and store systems treat a
JVM error such as OutOfMemoryError differently leading to the raw store
protocol violation errors
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1732?page=all ]
Mike Matrigali updated DERBY-1732:
----------------------------------
Summary: The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors (was: The langauge and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors)
> The language and store systems treat a JVM error such as OutOfMemoryError differently leading to the raw store protocol violation errors
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1732
> URL: http://issues.apache.org/jira/browse/DERBY-1732
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Reporter: Daniel John Debrunner
>
> Don't have the exact details, but remember noticing it a while ago. I think the store transaction context closes the transaction on such an error, while the language conneciton context just rollsback the transaction or the statement. I think the best and consistent approach would be to close the connection.
--
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