[
https://issues.apache.org/jira/browse/DERBY-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lily Wei updated DERBY-4856:
----------------------------
Attachment: DERBY-4856-part_1_1a.diff
Thanks to Kathey, due to the scope of the changes, I would like to purpose
three steps check-in to address this issue :
I.
1.1. Move ThreadDump.java from
java/shared/org/apache/derby/shared/common/sanity to
java/shard/org/apache/derby/shared/common/error
1.2. move dumpThreads method from AssertFailure to ExceptionUtil
II.
2.1 Add ThreadDump information to sane build in ContextManager.
cleanupOnError(). it will print the thread dump information to derby.log
III.
3.1 Add file handling as Bryan and Kristian's suggestion for ThreadDump info.
The current thinking is to add the file handling code as the method as utility
tool and calls it in ContextManager
I am attaching DERBY-4856-part_1_1a.diff for code review. The patching is
covering the part one change. I am running Suites.All and derbyall now.
> 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, derby-4856-1a.diff,
> DERBY-4856-part_1_1a.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.
