[
https://issues.apache.org/jira/browse/DERBY-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988185#action_12988185
]
Dag H. Wanvik commented on DERBY-4856:
--------------------------------------
Hi, thanks for the release notes, Lily!
Caveat, my comments below are not based on a thorough knowledge of
this new feature, I have just read about if cursorily, so if I got my
fact wrong, please forgive. Mostly, my change proposals are for
improved legibility.
> Summary of Change
>
> Derby will 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.
"will" -> "will by default"
"Users" -> "users"
Maybe add a sentence: "It is also possible to get thread dump and
diagnostic information" of errors with lower severity by adjusting a
property".
> 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 on derby.log. For ibm
> jvm users, a javacore file will be created.
I am not sure this content is correct for this section: The "symptom"
if any of existing systems would be that we don't get (or there is not
way to get ) enough state information when the system crashes or a
session level error happens.
> Incompatibilities with Previous Release
>
> N/A
"N/A -> None
I think "none" is better here, since incompatibilities is always a
relevant ("applicable") question for database changes.
> Rationale for Change
>
> The change intend to get more detail information relate to the staus
"The change intend" -> The intention of the change
"staus" -> status
> of Derby server when user hit system crash or server session error.
"Derby server" -> This applies to embedded usages as well? (i.e. not
limited to running with client/server. If so, maybe you can just use
"Derby" instead.
> Application Changes Required
>
> Users do not need to change anything for this change. If more thread
> dump information requires for error is has severity level less than
"requires" -> "is required"
"is has" -> that have"
> session error, derby.stream.error.extendedDiagSeverityLevel can be
Specify scope (database or system level) of property and whether it is
a dynamic or static property.
> set on derby.properties or as part of jvm argument. For example, if
"on derby.properties" -> in the file "derby.properties"
"jvm" -> "JVM"
> there is a deadlock issue and users would like to see thread dump
> information while deadlock is happening. Users can then set
2nd "deadlock" above -> "the deadlock"
". Users" -> ", users"
> derby.stream.error.extendedDiagSeverityLevel=30000 on either
"on" -> "in"
> derby.properties or as part of jvm argument.
"jvm argument" -> "JVM argument, e.g.
-Dderby.stream.error.extendedDiagSeverityLevel=30000"
> They can find the tread dump information on derby.log.
Change to "The thread dump information is found in the Derby error
log, typically this is the file "derby.log".
> derby.stream.error.extendedDiagSeverityLevel=30000 means
> turn on TRANSACTION_SEVERITY type of error.
last line -> "that the extended thread dump information for errors of
transaction severity or higher. Please consult the Derby documentation for
explanation of error severity and for
other possible settings of extendedDiagSeverityLevel.
> 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-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, derby.log, 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 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.
