[
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_3_3a.diff
Thanks to Kathey for reviewing the code. The new patch is ready for review.
Change in this patch compare to last one
1. For all the tests, assume we don't want the thread dump info except
T_b2i.java test. For T_b2i.java, I am testing the test can function correctly
if we get the database active information from LanguageConnectionContext object.
2. For the code path we know it is okay not to get the thread dump
information, we will assume database is not active
3. Change getSystenProperty to private in JVMInfo.java
Patch run clean on suites.all for sun jvm. I am still running derbyall test
suite for sun jvm.
There are two issues that are under investigation:
1. For ibm 1.6 jvm, ReplicationRun_Local still hang on
ReplicationRun.connectPing(...) where we try to do
DriverManager.getConnection(dbURL) on windows 7. The test did not hang with ibm
1.6 jvm on windows xp. The dbURL value is
jdbc:derby://localhost:1531/c:\derby3\trunk\testtmp\db_slave\wombat I am
thinking out loud here. Will change the path for the master and slave server
and using the new way to remove directory make the hang issue and intermediate
failure on replication tests behave better? Any suggestion is welcome.
2. For replication failover case, there are some javacore* files created
due to the current design of handling javaDump for ibm. Maybe we should just
not dump thread info in these cases?
Happy New Year!
> 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-4856_part_3_1a.diff,
> DERBY-4856_part_3_2a.diff, DERBY-4856_part_3_3a.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.
