[
https://issues.apache.org/jira/browse/DERBY-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-4856:
----------------------------------
Attachment: corruptdb.zip
I think ultimately the information should dump only for
ExceptionSeverity.SESSION_SEVERITY errors or higher if the derby engine is
booted, but while developing you may want to leave the boot check out and the
use this corrupt database which will fail to connect and produce a
ExceptionSeverity.DATABASE_SEVERITY error.
Lily also mentioned to me two other types of errors that might need to be
reported, java exceptions that don't get caught and wrapped in SQLExceptions
like some NullPointerExceptions and also it would be nice ultimate to include
low cost asserts in insane builds. I am not quite sure how this should be
accomplished.
> Add thread dump information when derby crash
> --------------------------------------------
>
> Key: DERBY-4856
> URL: https://issues.apache.org/jira/browse/DERBY-4856
> Project: Derby
> Issue Type: Bug
> Components: Services
> Reporter: Lily Wei
> Priority: Minor
> Attachments: corruptdb.zip
>
>
> On system crash or session ending error, Derby should dump as much
> information as possible. Such as: forcing a javacore if possible or at least
> thread dump and system environment information. This should only occur if a
> running session crashes not on boot error due to fail recovery etc.
> The IBM jvm provides a way to programmatically dump a javacore. i.e.
> com.ibm.jvm.Dump.JavaDump() And, the SUN jvm will force a thread dump using
> the Unsafe class and there may be a better way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
