[
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_2_2b.diff
Thanks Kathey for reviewing the code.
I attached the part_2_2b patch.
The threadDump varilable is removed from ExceptionUtil and the reflection is
using ThreadDump. The ThreadDumpUtil is rename to ThreadDump in iapi/error.
In ContextManager, the import is not being sorted. The getErrorCode Method is
renamed to getErrorSeverity and the javadoc format issues is modified. Add
commend says error only StandardException and SQLException are being handled at
this time.
build.xml and extraDBMSclasses.properties had been changed to reflect rename of
ThreadDumpUtil to ThreadDump.
> 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-4856_part_2_2b.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.
