[
https://issues.apache.org/jira/browse/DERBY-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968935#action_12968935
]
Kathey Marsden commented on DERBY-4856:
---------------------------------------
Thanks Lily for the patch.
For the new engine ExceptionUtil, I don't think the field threadDump is needed
or used. The reflection call should use the ThreadDump in engine, not the
shared one. I think then it will be fine for the engine ThreadDump class to
keep the original name, ThreadDump.
In ContextManager, there seem to be some javadoc formatting issues with the new
getErrorCode method, which might better be callse dgetErrorSeverity. I would
add a comment that errors that are not Standard or SQLExcetions are not handled
at this time.
]
> 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
> Assignee: Lily Wei
> Priority: Minor
> Fix For: 10.8.0.0
>
> Attachments: ContextManager.java, corruptdb.zip, derby-4856-1a.diff,
> DERBY-4856-part_1_1a.diff, DERBY-4856_part_2_2a.diff, derby.log
>
>
> 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.
