db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4856) Add thread dump information when derby crash
Date Tue, 01 Feb 2011 15:40:29 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989253#comment-12989253

Dag H. Wanvik commented on DERBY-4856:

Some further legibility improvement suggestions:

> Summary of Change
> Derby will by default dump as much thread dump and diagnostic
> information as possible on system crash or session error.
> i.e. users will find thread dump information with error severity
> higher than session error in derby.log.

Possible improvement:

On experiencing a system crash or session error, Derby will print as
much diagnostic information as possible to the Derby error log,
including stack traces of all threads.

> It is also possible to get thread dump and diagnostic information of
> errors with lower severity by adjusting a property.

This one is good, maybe change "of" to "for",

> Symptoms Seen by Applications Affected by Change 

> If errors have error severity level greater or equal than value
> derby.stream.error.extendedDiagSeverityLevel is set, thread dump
> information and extened diagnostic information will be handle by
> Derby. Users can find thread dump information in derby.log. For ibm
> JVM users, a javacore file will be created.

I still feel this information belongs in the first section, and that
this section should be N/A. I agree this is useful 

"handle" -> "printed"
"in derby.log" -> "in the Derby error log"

ibm -> IBM 

> Incompatibilities with Previous Release
> None

> Rationale for Change
> The intention of the change to get more detail information relate to

"relate" -> "related"

> the status of Derby when user hit system crash or server session
> error.  


"the status of Derby when important errors happen, "important" by
default meaning errors with session severity and higher. This will
help users, DBAs and support personnel to determine the exact cause of
the error condition."

> Application Changes Required
> Users do not need to change anything for this change. If more thread
> dump information is required for error that have severity level less
> than session error, derby.stream.error.extendedDiagSeverityLevel can

"derby.stream.error.extendedDiagSeverityLevel" ->
"the property derby.stream.error.extendedDiagSeverityLevel"

> be set in the file "derby.properties" or as part of the JVM
> argument. 

In stead of specifying "derby.properties" or JVM argument here,
wouldn't it be better to just state this is a Derby system property
and give a link to the documentation? System wide properties can also
be set programmatically. You could also say, here as an example, "for
example, in derby.properties" but not try to enumerate all ways it can
be set.


> For example, if there is a deadlock issue and users would
> like to see thread dump information while the deadlock is happening,
> users can then set
> derby.stream.error.extendedDiagSeverityLevel=30000 in the file
> "derby.properties" or as part of JVM argument,
> e.g. -Dderby.stream.error.extendedDiagSeverityLevel=30000.

See above comment, drop how to to set it here altogether, just show
the value required.

> The thread dump information is found in the Derby error log,

"The thread dump information" ->
"The diagnostics and the thread dump information"

> typically this is the file "derby.log".

> derby.stream.error.extendedDiagSeverityLevel=30000
> means turn on TRANSACTION_SEVERITY type of error that the extended
> thread dump information for errors of transaction severity or
> higher. 


"derby.stream.error.extendedDiagSeverityLevel=30000 means that extra
diagnostics and thread dump will be activated for errors with
severity equal to og higher than transaction severity (30000)."

> Please consult the Derby documentation for explanation of error
> severity and for other possible settings of
> extenedDiagSeverityLevel.


> 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, 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-4856_part_3_3b.diff, DERBY-4856_part_3_3c.diff, DERBY-4856_part_3_3d.diff, DERBY-4856_part_3_3e.diff,
DERBY-4856_part_3_3g.diff, DERBY-4856_part_3_3g_1a.diff, DERBY-4856_part_3_3g_2a.diff, corruptdb.zip,
derby-4856-1a.diff, derby.log, releaseNote.html, releaseNote.html, releaseNote.html
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message