db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lily Wei (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4856) Add thread dump information when derby crash
Date Fri, 31 Dec 2010 22:51:45 GMT

     [ 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

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:
>         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
> 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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message